在做
排班规则小工具
围绕请假、连续值班、最低在岗人数等常见约束，模拟一周班表并标出规则冲突。
做到后面才发现，算出一张表不难，真正费时间的是把“为什么排不开”解释清楚。
- Java
- Spring Boot
- PostgreSQL
- Vue 3
2011 — 现在
Java 和 Web 开发。
这个站记录技术实践、思考与沉淀的个人工地。放几个自己做的小工具，也记下改过的 bug、踩过的坑，以及后来想明白的事。
真实约束持续复盘
PROJECTS
个人项目
打样
日志时间线整理器
导入多服务日志，统一时间格式，再按 requestId 或 traceId 排成一条时间线；解析只在浏览器本地完成。
最麻烦的不是排序，而是时区、缺失毫秒和不同机器之间的时钟偏差。
- TypeScript
- Astro
- Web Worker
- IndexedDB
试验
状态流转小实验
用重复回调、乱序消息和超时重试模拟一笔请求的完整生命周期，观察幂等和状态机边界。
重复消息不可怕，怕的是状态更新、业务副作用和消息确认没有明确边界。
- Java
- Spring Boot
- RabbitMQ
- MySQL
- Testcontainers
随手记
改动决策记录
用 Markdown 记录改动背景、候选方案、最终选择和回看日期，避免最后只剩一段看不出原因的代码。
回看时最有用的不是结论，而是当时放弃了什么、什么条件下应该重新评估。
- Markdown
- Astro
- Git
CASES
公开案例摘记
Google OR-Tools
一张排班表，至少要先说清五件事
Google 的餐厅排班示例把班次、岗位覆盖、员工可承担岗位、个人请求和优先级分开建模。这样得到的结果不只是一张表，还能解释哪条约束没有满足。
- 约束
- 排班
- 可解释性
Amazon Builders' Library
超时以后，先别急着重试
Amazon 用资源创建说明一个常见问题：响应没回来，不代表操作没有成功。调用方需要带稳定的请求标识，服务端也要保证请求记录与业务变更一致，重试才不会制造第二份资源。
- 重试
- 幂等
- 一致性
Tailscale
一个 16 年的 SQLite bug，是怎么被日志抓住的
Tailscale 在六个月的偶发故障中逐步补上完整性检查、事务重放和文件系统跟踪，最终定位 WAL 重置与写事务之间的竞态。关键不是日志越多，而是每次新增证据都能排除一个假设。
- SQLite
- 日志
- 竞态
NOTES
最近记下的几件事
关于“重写一遍”的冲动
旧代码不一定坏，很多时候只是我还不熟。先找到真正卡住变化的地方。
返回成功，也可能需要重试
接口返回、消息确认和最终落库是三件事。少看一层，失败就可能被悄悄吞掉。
数据修复前先查什么
范围、关联记录、当前状态和可回退条件。能用一条小更新解决，就不写复杂脚本。
文档里的“已验证”
编译通过、测试通过、发布成功和业务可用不能写成同一句话。
ABOUT
关于
技术换了很多轮，真正反复有用的东西倒挺朴素：
- 动数据之前，先把查询结果留好。
- 线上出问题，先留现场，再讨论是谁的锅。
- 能小改就不大改；真要重写，也先想清楚怎么退回来。
- 代码验证、发布观察和业务验收，分开说。