打包工具的界面不能信
折腾了一天打包。中间一直纠结某个选项在界面上找不到，后来想明白了： 与其猜界面，不如直接查产物 —— 打出来的东西里到底有什么是客观事实。
写了个小脚本把包解开看内容。第一版有个很蠢的 bug：某个字段读到空值， 而空值又不等于我要排除的那个错误值，于是判成「通过」。 一个会让人放心地用错东西的误判，比直接报错危险得多。
教训是：校验工具不要去「提取」再猜，要拿期望值去「验证」存在性。 前者会给你一个理直气壮的错误答案。
记一些自己折腾的东西
折腾了一天打包。中间一直纠结某个选项在界面上找不到，后来想明白了： 与其猜界面，不如直接查产物 —— 打出来的东西里到底有什么是客观事实。
写了个小脚本把包解开看内容。第一版有个很蠢的 bug：某个字段读到空值， 而空值又不等于我要排除的那个错误值，于是判成「通过」。 一个会让人放心地用错东西的误判，比直接报错危险得多。
教训是：校验工具不要去「提取」再猜，要拿期望值去「验证」存在性。 前者会给你一个理直气壮的错误答案。
同一个目录下：.ps1 必须有 BOM，.bat 必须没有，
.sh 不但不能有还必须是 LF 换行。任意一条弄错，
报出来的错误都跟真正的原因毫无关系 —— 比如中文被按错误编码解析后，
产生出的字节恰好是命令行的特殊符号，于是命令被从中间劈开。
明明记在笔记里了还是又踩了一次。所以后来干脆写成自动检查， 不再靠记性。凡是「知道了也还会犯」的事，就该交给机器。
脚本里开了 pipefail，然后写了 某命令 | grep -q 关键字。
grep -q 一匹配到就立刻退出，上游还在往管道里写，
收到 SIGPIPE 返回 141 —— 于是明明匹配成功，整条管道却被判为失败。
更麻烦的是后果：脚本据此认为某个东西「不存在」，只打了一句警告就继续跑完， 最后报「全部完成」。而实际上关键的一步根本没执行。 表面一切正常，是最难查的那种。
服务重启后接口返回 200，就能说明新代码生效了吗？不能 —— 旧进程照样返回 200。
后来改成看进程的运行时长：刚重启完却已经跑了几分钟，只有一种解释。 同理，报版本号要报运行中的服务吐出来的， 而不是磁盘上文件里写的 —— 读磁盘只能证明文件更新了。