数据采集任务的调度设计：从定时脚本到可观测的任务系统
最早的采集脚本只有一个定时任务条目，出了问题只能翻日志。任务变多之后，失败重试、并发限速、 结果核对都需要专门设计。这篇记录我重新拆分调度层的过程：任务状态机怎么定义、 重试策略怎么避免雪崩，以及为什么最后放弃了“什么都自己写”的想法。
技术心得
这里记录我在实际项目中的技术判断与实现细节。写下来的目的有两个：一是把思路整理清楚， 二是希望后来遇到同类问题的人能少走一点弯路。内容以工程实践为主，尽量给出可复用的做法，而不是泛泛而谈。
文章列表
按发布时间倒序排列，不定期更新。
把响应时间从 800ms 压到 120ms：一次慢查询的完整排查
用户反馈列表页变慢，但监控指标看起来一切正常。从慢查询日志、执行计划到索引调整， 一步步定位问题所在。后半部分写了缓存策略的边界：哪些数据适合缓存、什么时候缓存反而会增加复杂度。
一个人维护开源项目，我是怎么处理 Issue 和 PR 的
维护开源项目的时间大多花在沟通上。分享我用来给 Issue 分类、给出明确反馈、 控制合并节奏的几条朴素规则，以及怎样礼貌但清楚地拒绝不合适的贡献。
接口返回结构统一之后，我反而后悔了
统一响应格式是常见的团队规范，但在业务差异较大的场景里，强行套用同一层壳会带来额外的转换成本。 这篇讨论我在两种方案之间反复调整的取舍依据，以及最终采用的折中做法。
把重复的部署步骤写成脚本，节省的是注意力而不是时间
自动化脚本省下的时间其实有限，真正的收益是不必在每次发布时重复回忆细节。 这篇整理了我在个人项目里常用的几条约定，以及一个小型发布脚本的设计思路。
读源码的正确方式：带着问题去读，而不是从头读到尾
我曾多次尝试从头读完一个项目的源码，结果都停在前几层调用里。 这篇分享一个更有效的路径：先写一个最小可运行示例，再顺着调用链追踪，把疑问逐个消除。
站内文章均为个人原创技术分享，欢迎交流讨论。如需转载，请注明出处并保留原文链接。
后续会陆续补充更多主题，包括工具使用、调试技巧与项目复盘。