我还是觉得 体积（你的房钱啊）+初期投入 远大于 那一丁点电费差异了。各种传统品牌机的 SFF(Small Form Factor)洋垃圾挺好的。

尤其老一点的 SFF 洋垃圾更便宜，带的 3.5 寸又多。新一点的尽管小一点点，但是 3.5 寸位就少了。要知道：一个 3.5 寸=4 个 2.5 寸位，一个 5.25 寸位=一个 3.5 寸+2 个 2.5 寸位。

除了单纯体积还有一点很关键的：可堆叠、可堆叠、可堆叠。你别看那种啥 itx 小机箱、啥 minpc 主机，能够满足可堆叠的有几个？

可堆叠，就意味着前后进出风道，你完全可以把他往哪个架子上一丢：横躺着在上面再叠个机器；纵向摆着融入开放式书架啥的都行。家用机器不上机柜，可堆叠真的省地方。

420 块一个 HP z230 全套洋垃圾，i3-4150 的 u ，还送个 128 的 SSD 启动盘。可以插 3 块 3.5 寸盘（其中一块在 5.25 上）。
我觉得这个挺好了，33.7x28.7x10cm=9.7L

一般来说，你前面还是要过 DNS 的
当然也有很多浏览器插件会帮你把 DNS 解析动作改到经过代理请求

比较简单的话，一般是直接开个 L2TP VPN 之类的翻回家

类似 TP-LINK 路由火墙全挡 ipv6(部分型号可以问客服要测试固件开启)情况还存在的话

这些就都还有活路

@mengzhuo

哎，数据库 loader 工具不是又依赖 insert 的…
不是我不懂 SQL 注入，而是你不知道哪些做法不会引起注入……

SQL 注入的优良解决方式不是依赖过滤的，而是依赖 SQL 执行侧上正确的变量绑定、包括我上面所说的使用数据库厂商的文本数据 loader 工具。这些是不会引起注入的。

过滤不是个完善的实现。

哦，还想起来一个场景，对于一些数字形字符是否有隐式转换为数字，造成对数字可以用上索引之类的。可能在不同的接入客户端模式上也有不同。对应的 preparestatement 或者 orm 框架上，对应的既能数字、也能文字的字段类型，是否正确绑定，用上了索引。

@crasa 还是看下执行计划吧，有分页也会再被 fetchsize 最终再限制

可能是终端和程序调用时上 fetch 条数的默认设定不同导致，终端默认 fetch first 50 或窗口大小可显示条数，导致执行计划和实际开销都优于，程序默认调用全量返回数据的执行计划和实际开销

可以尝试通过程序侧调用执行计划获取一下，比对一下终端都执行计划

最终程序执行上要考虑耗时功能优化翻页等等

如果上报指的是上报监控类信息的话，为啥要选择长连接方案？

业界标准上对于上报非关键信息的话，短连接 UDP 已经是标准做法了吧。突破现有标准做法的是有什么特殊需求目的、和环境特异性么？

@mengzhuo 上传 shell 又不会被执行的……只会被 sed 处理、按 loader 工具按照预定的分割规则进行分隔符切割/定长分割处理后由工具入库，工具也不会用 SQL 引擎解析其中文字。读帖首先看题干看题干看题干…

这么多信息，S 在其中……感觉是出题的干扰选择项嘛

A 和 B 的通信是否安全，现在就归结于拿到了 K 的 C 怎么使用 K 了

如假设：
1 、B 没有告诉 C ，有 S 的存在，C 通过自身能力、也无法获知 C 的存在与对应调用方法，粗且可以认为 A-B 是安全。
2 、B 告诉了 C ，有 S 的存在，但一般来说，S 对于 B 的交互注册，有名为 KS 的 key 存在，对 KS 尽管 B 喝醉了、B 没有 C ，那么粗且可以认为 A-B 安全

另外，以上假设是从 B 对 C 的情况已经透明可知的情况，如果对于 B 并没有把喝醉这件事情记起来、更没有告诉 A 。那么从 A 视角来看，还有 A 认为 A-B 间是否安全的问题。

从严格的安全角度来看，既然 K 已经泄露了，第一时间更换 K ，是比做上述各种假设更为安全的选择。

jvm 总体不要设过容器一半。各种 gc 相关参数打开、oom 时就能产生 heapdump ，拿出来分析内存溢出/泄露对象

还有：@imyasON

不要 不要 不要 随便随便就设置等同的 xms 和 xmx 。当堆内用量情况很平稳没有升代、长时间不需要 fullgc ，没有 fullgc 就有不能触发挂载在 finalizer 上的资源回收，可能导致包括堆外溢出等各种各样的资源耗尽问题。在确认没有堆外资源、没有 finalizer 依赖等等情况下，已经做过深度优化的基础上再考虑 xms=xmx 的设定。

Windows 默认输入法 bug ，要选择使用兼容性老版本

健康又卫生不得不尝

https://www.zhihu.com/question/389219452

洋垃圾准系统一套 200~300 ；+30 、40 一张千兆网卡
足够了，真讲划算比混这个再说吧

@mengzhuo 这正是用各类 loader 工具而不用自己代码程序的好处，各类 loader 工具和程序 sql 的差异了解下？

@hzjseasea 因为稍微正经点的数据库，都会有在 shell 下能够直接用起来的，配套文本导入工具/命令行功能。Oracle 的 sqlldr ； MySQL 的 LOAD DATA ； PG 的 COPY FROM 等等。原生直接对接数据库，速度快，不用再研发。数据库运维掌握这些工具是必备技能，出了啥问题也是运维和数据库公司支持方面搞定。（其实多少也是为了研发可以推点活到运维吧）

@jptx 恩，这就是比老老实实手动编码的思路，更老老实实的思路了。确实有道理，展示层进出的时候就弄掉，中间一路干净也是是正道。

能发送返回 http 就是浏览器

能解析 html 就是浏览器

能 render 页面就是浏览器

能执行 js 等动态脚本才是浏览器

来画个九宫格？

@NessajCN 后端要交出这块数据处理调用给到二次开发手里的，既然是二次开发，就要选择最没有依赖、人人都能用起来的语言环境=>我选择 shell 作为首先要支持的语言环境、或者由二次开发选择通过 shell 再调用他们自己研发的语言代码的入口。