@COW U 盾本来就是为了防止用户机上有木马，被盗号以后和银行扯皮。如果因为一个抓包软件就被破解了，那木马早就该集成这种功能，那 U 盾不是笑话吗？（虽然中国银行业可能笑话不少，但是这种技术已经很成熟的产品不会出什么问题）

你还没有买盘柜和 FC 交换机的话建议思考一下你是想尝试软件 RAID 还是硬件，因为很多 FC HBA 是可以刷成以太网模式用。另外你的目的是什么呢？自组 NAS 还是学习企业储存方案？

SAN 模式的话你储存的分布和冗余一般是在 SAN 内部完成的，这样你用 Ceph 和 ZFS 等基于软件的储存方案好像没什么意思。具体来说：

ceph 主要是基于(IP)网络的分布式储存，是利用很多不冗余的电脑和储存实现一个冗余的储存系统。类似于虚拟一个可 Scale 到数据中心级别的 SAN 。你要是有 SAN 了，就不需要虚拟一个。

zfs 的主要卖点是集成了 RAID 和 check sum 两种数据冗余技术，并通过复杂的缓存实现高性能。但是 SAN 通常是通过硬件实现 RAID 的，你把硬件 RAID 关掉用 ZFS 除了增加 CPU 负担以外延迟也比较高。

你现在除了 SAN 卡还有什么硬件呢？我现在觉得你问这个问题是你还没有规划好你想怎么搞储存是不是？

你的卡是 SAN 模式还是以太网，后者的话你又没说是什么配置。

你在 dev tools 里面是编辑的同一个父元素吗？比如有没有可能你代码里选择的是<table>但是 dev tools 里面是<tbody>，然后它样式是针对 tbody 的？

@vfx666 等等，一楼问你 xid 大小有没有超过 2 ，你二楼回答没有。那 xid 的大小会不会不到 2 ？你加的 if 是检测 xid 的长度吗？不是的话能不能加一个试试？可能其他部分就有 bug ，导致 xid 偶尔不到 2 个长，之前没有做 erase 所以没有发现？

然后，11 楼说的是很有可能的，因为你这行代码虽然不执行，但是为了能执行这行代码，编译器可能改变了堆栈帧的长度，或者初始化了某些信息，这导致其他（已有的）代码 overflow 到了更关键的地方。

但我们这都是凭空猜测，你要想方设法弄到个 stack 。

既然用了 Mybatis 估计不是纯粹运行简单 SQL 而是至少有一些动态 SQL ，你也不运行代码的情况下是无法自动打出所有可能的 SQL 的，否则就是解决了 halting problem ，要不你把 Mapper.xml 人工分析一下。

你是怎么定位到这行代码的？

这代码看上去人畜无害，除非编译器认为 xid.size()必定小于 2 ，于是编译了个 undefined behavior 进去？

当然编译问题也是有可能的，你有保留这行代码然后 clean 编译过一次吗？

把整个 so 当成外部库写进新逻辑里，然后编译的时候作为静态引用，就能合并进新的 so 里面了。稍微手写一个工具确保新项目引用一下原 so 里面每一个 symbol.

一是吸引各种用户把内网的资源都上传上云，然后在下载的时候收钱。

二是绝大多数云服务都是出站远多余入站，但是所有接入专线都是对称的，这样的话入站的网络资源很多都是闲置的，干脆免费

@povsister #6 楼主的烦恼和 int 和 bool 在内存的布局其实关系不大吧，需要用这个变量的时候都是要把它读进寄存器的，不管在内存里是多长，寄存器都是至少 int 那么长的。

现在因为 golang 缺乏这个转换，还要专门写个条件判断，指令上至少一个比较+一个条件跳转+两次立即数载入，那个条件跳转还容易产生分支预测错误，整体属于掏肠子放屁。

有夏令时的国家出产的软件自然需要对时区和时间非线性变化处理得很好，其实是高质量的代码。中国等固定时区国家的程序员没有这个意识，经常假设从系统读出的日期时间是线性不会跳跃的，导致用户休眠、跨国旅游或者手动调整电脑时间以后就出现各种 bug 。

至于 110V 和英制，世界上只有极少数几个国家还采用。这些历史遗留很多政府都考虑改过，美国还有一条公制高速公路，但最终因为民间阻力而作罢。英国倒是成功转换成了公制为主，在某些已经深入人心的场景（比如啤酒杯大小、房屋面积、道路限速）才保留英制整数。

空气能可以和太阳能共用一个热水箱，这样不管什么天都能有足够热水。但其实夏天用空气能热效率能有 500-600 ％，不装太阳能也罢。

网络连接都是双向的，你觉得是连回国，在墙眼里都是翻墙流量，不可能给你容易的。

你现在有好用机场的话在里面再套一个 VPN 到便宜的海外 VPS ，再搞一下路由表就是自建回国 VPN 了。

理论上是供电和检测插拔的针脚是不同的，不知道有没有人造禁止协商的 USB-C 线？

Android 是可以设置 USB 是哪边控制供电，但也有很严重的兼容性问题