慢查询并不总是“少了一个索引”。优化器会在顺序扫描、索引扫描和各种连接算法之间估算成本；即使索引存在，它也可能判断直接读表更便宜。与其凭感觉加索引，不如先读取执行计划，确认数据库实际做了什么，再用数据验证改动是否有效。
把配置加载做稳：分层覆盖、显式优先级与启动校验
配置出错往往不像代码缺陷那样立刻抛出堆栈：测试环境的地址被线上变量覆盖、超时值从 5000 变成字符串、临时命令忘记撤销，服务仍能启动，却在流量进入后表现异常。要让配置可靠，关键不是再增加一个 .env 文件，而是让来源、优先级、类型和生效结果都可解释。
用 Transactional Outbox 把领域事件发布做稳
创建订单后既要提交订单数据，又要通知库存、积分或搜索系统；这两件事若分两步完成，就会留下危险的中间态：数据库成功而消息没发出，或消息已发出而事务随后回滚。Transactional Outbox（事务外盒）把“待发布事件”与业务数据放进同一事务，让可靠性先落在最擅长提交的数据库里。
把 Webhook 接稳：签名校验、重放防护与可追溯处理
Webhook 把“定时去问对方有没有变化”变成“变化发生时由对方通知我”，很适合支付结果、代码仓库事件和订阅状态同步。但它的入口暴露在公网，收到一段看似正确的 JSON 并不等于事件可信：攻击者可以伪造请求，网络也会带来重复投递和乱序。要把 Webhook 接稳，应把验真、限时、去重和异步处理视为同一条防线。
把 SSH 隧道用明白：本地转发、远程转发与 SOCKS 代理
数据库只允许内网访问、本地服务需要临时给远端联调、浏览器要经过跳板机访问测试环境——这些场景不一定要先搭一套 VPN。SSH 端口转发可以借用已有的登录链路建立加密通道，但三个常用参数 -L、-R、-D 的方向很容易混淆。本文从“监听发生在哪里”出发，把它们一次讲清。
把 API 限流做对：令牌桶、分布式配额与降级响应
限流不是简单地把“每秒 100 次”写进网关。突发请求是否允许、配额按用户还是按接口计算、多个实例如何共享计数、拒绝后客户端怎样恢复，都会决定系统是在高峰期有序降速，还是制造更多重试。可靠的限流应该既保护容量，也保持公平，并给调用方清晰、可执行的反馈。
把常驻进程交给 systemd：Unit、重启策略与最小权限
把程序放进后台运行并不难，难的是让它在机器重启后自动拉起、崩溃时按规则恢复、日志有处可查，还不能拿着不必要的 root 权限。与其维护 nohup、PID 文件和自制守护脚本，不如把进程生命周期交给 systemd，用一份 Unit 文件明确启动条件、资源边界和失败策略。
用 Git Bisect 二分定位回归：把“哪次改坏了”交给自动测试
功能昨天还正常，今天却悄悄坏了。面对几十甚至几百个候选提交，逐个回退既慢又容易漏掉环境差异。git bisect 会在一段提交历史上执行二分查找；只要能稳定判断某个提交是“好”还是“坏”，就能用很少的检出次数逼近第一个引入问题的提交。
Linux 权限别再 chmod 777：读懂目录执行位、umask 与 ACL
服务报出 Permission denied 时，最省事的处理似乎是 chmod -R 777。它往往能暂时消除报错，也同时把读、写、执行能力交给了所有本地用户；更麻烦的是，真正缺失的权限可能位于父目录、进程身份或 ACL，放开目标文件只是在掩盖原因。理解 Linux 如何逐层判断访问权，才能给出刚好够用的权限。
把文件上传入口守住：限额、识别、隔离与安全发布
头像、附件和数据导入看起来只是“接收一个文件”，实际上却把磁盘、解析器和下载域名同时暴露给了不可信输入。只检查扩展名或请求头，挡不住伪装类型、超大文件、路径穿越和带主动内容的文档。稳妥的设计不是再补一个判断，而是建立一条先隔离、后验证、最后发布的管线。