用户已经登录的站点若用 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 把上限、权重和观测数据绑定到同一个工作负载上。
异步任务别“放养”：用结构化并发收拢生命周期、取消与超时
一次请求同时查询库存、用户和优惠信息，看似只要创建三个异步任务就能提速。但如果请求已经失败，其中一个任务仍在后台写数据；或者主协程被取消，子任务却继续占用连接，并发就从性能工具变成了隐形故障源。结构化并发的核心不是某个库，而是一条所有权规则：任务必须属于一个明确的作用域，离开作用域前必须全部成功、失败或被取消。
子进程为什么卡住不退出：管道背压、死锁与正确回收
调用外部命令时，测试环境里几行输出一切正常，到了 CI 却偶尔永远不退出。进程仍在、CPU 几乎为零，强制终止后也没有明确错误。问题往往不在命令本身，而在父进程只等退出、没有及时读取管道：日志把缓冲区写满后，双方就互相等待。
断点下载不只是加个 Range：HTTP 字节范围、校验器与文件拼接
大文件下载到 90% 时网络中断，最浪费的做法是从头再来。HTTP 字节范围请求允许客户端只取缺失部分，但可靠的断点下载绝不是把新响应直接追加到旧文件：服务器可能忽略范围，资源也可能已经更新。只有同时验证状态码、范围边界和资源版本，拼接后的文件才可信。
金额计算别用二进制浮点：定点数、舍入规则与对账边界
订单明细相加差一分钱、退款金额与原支付对不上、同一张账单在两个服务里得到不同结果，通常不是算术能力出了问题，而是系统没有约定金额的表示方式、舍入时机和余数归属。金额计算要追求的不是“看起来差不多”，而是每一步都可复现、可解释。