mac 我都是设置鼠标滑角落

@LavaC macbook 还好，有一个三眼的转接长线在你包装里的，换上、就可以优先走三眼接地铜线走掉了；而不是走你人体了。ipad 古早的版本，也有大插头配可以三眼转接的，但最近的都是两眼小插头，那就是避免不了电麻麻了。

以前用过红外形式的，有误触发问题

1 、会被风吹动的衣服、窗帘等误触发
2 、会被宠物触发

如果有能够解决这两个问题的，那就是真不错

@RogerL 其实还是有挺多选择的

1 、入 E3 神教，直接 1230v3 ，用差价换电费；洋垃圾准系统货源充足 7x24 稳定性久经考验

2 、正常装机，用 AMD 早先代的 U

3 、AMD 7735HS 、5825/5800U 之类的小厂小主机/准系统

4 、N305 主机/准系统的小厂小主机/准系统

零刻和小厂工控机，我都是视为同类水平的，不及 1 、2 的稳定性。

古老的 socks5cap 、wincaps 就都行

@luckzk 淘宝搜 z230sff 、dell 准系统之类的，一大堆，那些店里随便翻翻几百块钱包垃圾佬满意的水平

我选择 SFF 框架的 HP/dell 的 9L 左右的洋垃圾小主机
盘位足够，大小合适，低耗电，在其之上玩黑苹果的人也多

捡垃圾充满快乐
3 年的机器现在只要 1/3 的价格就能买
10 年前的机器现在只要 1/25 、几百块的价格能买

然后做个 NAS 、软路由都是性能过剩，捡垃圾有啥不能用
不到 1/10 的价格，超越现在一手 NAS 10 倍的性能，带来无聊的优越感

我都是用自己大奶机淘汰下来的非 ecc 机器控制跑手机集群
大约 11 年，迄今为止出现的故障：

1 、最老的一台机龄 15 年的机器主板网卡应该有点小故障，约 3 个月会断一次网，对于无头设备来说挺不友好的。设置了操作系统快捷键+脚本重启解决。
2 、次老的一台机龄 14 年的笔记本在其作为主存储节点的第 3 年 HDD 损坏，磁头打盘应该是马达挂了。后续换用台式机做主存储节点并改用 SSD ，至今没有硬盘损坏。

其他从未出现过任何内存故障、死机故障等问题，包括手机集群大量使用 USB 端口，USB 工作也没出现过问题。

使用的包括联想、acer 的笔记本； hp&dell 的洋垃圾准系统+各种二手配件；自己搭的组装机大奶机淘汰。都没啥大问题。

我感觉现代计算机的质量 7x24 还是基本可以的。倒是自己最新的一台联想刃系列大奶机，作为自己游戏机和平时做 console 形式的节点，7x24 小时 3 年 2 个月之后，一次关闭后再起不能，主板损坏。电脑不关就不会坏啊！

我还是觉得 体积（你的房钱啊）+初期投入 远大于 那一丁点电费差异了。各种传统品牌机的 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 已经是标准做法了吧。突破现有标准做法的是有什么特殊需求目的、和环境特异性么？