进程收到 SIGTERM 后要停止接流量，收到 SIGHUP 后要重载配置，看起来只需注册两个回调。然而信号处理函数会在不可预测的指令之间打断程序；若在里面加锁、分配内存或写日志，偶发死锁和状态损坏便可能随之而来。稳妥的思路是：处理函数只负责通知，把真正的工作交还主循环。
Python 资源清理别靠记忆：用上下文管理器守住异常路径
文件能正常关闭，不代表代码已经可靠：读取中途抛异常、获取第二个资源失败、函数提前返回，都可能绕过散落在各处的清理语句。Python 的上下文管理器把“获得资源”和“无论如何都释放资源”组成一个边界，让异常路径与正常路径共享同一套收尾逻辑。
用 heapq.merge 合并有序日志：惰性归并、排序前提与稳定次序
排查跨服务故障时，常要把几个日志文件合成一条时间线。如果文件很大，全部读进列表再排序会占用大量内存。只要每个文件内部已经按同一规则排好序，就可以用多路归并逐条输出，让内存需求主要取决于输入路数。
别把 SameSite 当万能药：CSRF 防护的令牌、来源校验与上线清单
用户已经登录的站点若用 Cookie 保存身份，浏览器会在满足条件时自动带上它。攻击者不必偷到 Cookie，只要诱导用户在另一个站点提交表单，就可能让目标站点误以为这是用户本人的转账、改邮箱或解绑操作。这就是跨站请求伪造（CSRF）。可靠的防护不是单押某个响应头，而是先缩小 Cookie 的跨站发送范围，再让服务端验证请求确实来自自己的页面。
HTTP 缓存别靠猜：Cache-Control、Vary 与条件请求实战
页面明明更新了，用户却仍看到旧内容；接口接入 CDN 后，不同用户的数据竟然互相串了；静态资源每次访问都重新下载。此类问题往往不是“缓存失效了”，而是响应没有说清楚谁能缓存、能用多久，以及哪些请求对应同一份表示。HTTP 已提供完整的表达方式，关键是把策略写成可验证的响应契约。
Python 导入为何出错：同名遮蔽、模块缓存与循环依赖
依赖明明装好了，导入却提示属性不存在；改了源码，交互终端仍执行旧逻辑；两个文件各自正常，放在一起就报错。这些现象常被归咎于环境，其实需要先回答三个问题：导入了哪个文件、是否复用了缓存、访问时模块有没有初始化完成。
容器隔离的另一半：用 Linux Namespaces 看懂进程、网络与文件系统边界
容器看起来像一台独立的小机器，但它并没有启动新的内核。进程、网络接口和挂载点之所以“看不见彼此”，关键靠 Linux Namespaces（命名空间）。它解释了容器里的 PID、localhost 和排障入口。
SQL 窗口函数别算错：分组排名、累计值与窗口边界
报表既要展示每笔销售，又要附上门店排名和累计金额。用分组聚合会丢失明细，拉回应用层计算又增加数据传输。SQL 窗口函数能直接为每行补上统计结果，但排序并列、默认窗口和过滤位置都会改变答案。把这些规则写清楚，查询才经得起真实数据的检验。
Linux cgroups v2 资源治理：CPU、内存、IO 限制与 OOM 排障
当一台机器同时运行 Web 服务、批处理和构建任务时，“放进容器”不等于资源已经被治理。没有配额时，构建进程可能吃光内存，邻近服务被 OOM killer 终止；CPU 抢占和磁盘 IO 争用也会让延迟抖动。cgroups v2 把上限、权重和观测数据绑定到同一个工作负载上。
异步任务别“放养”：用结构化并发收拢生命周期、取消与超时
一次请求同时查询库存、用户和优惠信息，看似只要创建三个异步任务就能提速。但如果请求已经失败，其中一个任务仍在后台写数据；或者主协程被取消，子任务却继续占用连接，并发就从性能工具变成了隐形故障源。结构化并发的核心不是某个库，而是一条所有权规则：任务必须属于一个明确的作用域，离开作用域前必须全部成功、失败或被取消。