浏览器提示“连接不安全”时，重新签发证书并不一定能解决问题。错误可能来自 SNI、主机名、有效期、中间证书、客户端信任库，也可能是负载均衡器仍在提供旧证书。有效的排障方式，是保留握手证据，再把“连接、身份、信任、部署”逐层拆开。
Linux 内存告警别只看 free：RSS、PSS、Page Cache 与 OOM 排查
服务器提示“内存快满了”，第一反应往往是找出 RSS 最大的进程，甚至直接重启服务。但 Linux 会主动利用空闲内存缓存文件，同一份共享页也可能被重复计入多个进程。先分清指标含义，再沿着系统、cgroup、进程三层收集证据，才能判断是正常缓存、真实泄漏，还是容器限额过小。
别让制品悄悄变质：SHA-256 校验、清单与内容寻址
安装包能解压，不代表它就是构建机产出的那一份；对象存储返回成功，也不代表每一层传输都没有截断或串包。要让发布结果可验证，关键是为确定的字节建立稳定身份，并让生产者与消费者在同一边界计算它。
把事务并发做对：隔离级别、锁与冲突重试
事务能保证一组操作一起成功或失败，却不等于并发执行时业务结果一定正确。两个请求同时读库存、计算新值再写回，即使都提交成功，也可能覆盖彼此的修改。解决这类问题，关键不是机械地把隔离级别调到最高，而是先写清业务不变量，再为具体冲突选择原子更新、锁或版本检查。
DNS 故障别靠刷新：用 dig 分层定位解析链路
域名打不开时，反复刷新、清浏览器缓存或直接改 hosts，往往只会暂时绕过问题。DNS 不是一次简单查询，而是一条包含本机、递归解析器、根与顶级域、权威服务器的缓存链路。排障的关键，是先确认“谁给出了什么答案”，再逐层缩小故障范围。
把时间处理做对：墙上时钟、单调时钟与时区边界
定时任务晚了一小时、接口明明只跑了两秒却被统计成负数、跨地区订单显示成“昨天”——这些问题往往不是计算写错了，而是程序把不同含义的“时间”混在了一起。时间处理的第一原则，不是统一格式，而是先明确用途。
把文件写稳：原子替换、fsync 与崩溃一致性
配置、缓存索引和本地状态看似只是“小文件”，却常在进程被杀、机器断电或两个实例同时写入时变成半截 JSON。可靠写入的关键不是多调用一次 write，而是分清原子可见性与持久化，并按正确顺序提交数据。
把 CSP 落稳：从 Report-Only 到 nonce 的渐进防护清单
一次遗漏的输出转义、一个被污染的富文本字段，都可能让脚本进入页面。内容安全策略（Content Security Policy，CSP）能让浏览器只执行可信来源的资源，为 XSS 再加一道边界。但直接上线严格策略，往往先把统计脚本、字体和业务代码一起拦掉。更稳妥的办法是先观察、再收敛、最后阻断。
文件描述符为何越用越少：用 /proc、lsof 与 strace 定位泄漏
服务运行几天后突然报出 Too many open files，重启又恢复正常，通常不是“机器偶尔抽风”，而是某类文件描述符只打开、不释放。文件、Socket、管道和事件通知在 Linux 中都占用描述符；泄漏增长得很慢时，故障甚至会跨过多次常规监控窗口。定位它的关键，是先证明数量持续增长，再找出增长最快的资源类型，最后回到创建与关闭路径。
别只枚举样例：用 Property-Based Testing 自动寻找边界反例
传统单元测试由开发者挑选几个输入，再核对预期输出。它对已知场景很有效，却容易漏掉空数组、极端整数和意外组合。Property-Based Testing（基于性质的测试）换了一个角度：先描述对所有合法输入都应成立的规则，再让工具批量生成数据、寻找反例，并把失败输入缩减到最容易理解的形态。