一次分表键选错，把我们整张表拖垮了
凌晨数据库告警揭示分表键选型错误引发的严重数据热点：以shop_id分片导致头部店铺流量集中，单一分片过载拖垮全表。复盘发现分表键应优先保证数据均匀度而非查询覆盖率，最终选择buyer_id并辅以路由索引表解决非买家维度查询。通过双写与存量回填完成平滑迁移，负载均衡显著改善。总结出分表键选择方法论：均匀度优先、二级索引补位、复合键无效、压测验证。
SPA 路由一换，CLS 和 LCP 的测量就乱了——我是怎么在切换后强制重算的
SPA 路由切换时，浏览器原生 PerformanceObserver 不会重置 CLS 和 LCP，导致数据残留或混杂。解决方案是在路由变化时主动断开并重建 Observer，清空 CLS 累加值，用自定义时间戳过滤旧条目，并延迟上报至页面稳定。文章还给出了 Vue/React Router 的接入示例和常见问题处理。
流式响应的断点续传：前端怎么记住读到哪一行了
断点续传的正确锚点是服务端返回的事件 ID，而非客户端行号。文章详解了 SSE 协议中 `id` 字段的用法，并给出了一套生产级方案：手动解析流时提取事件 ID，前端通过去重队列和防抖持久化记录消费进度，重连时用请求头传递断点，服务端据此从指定位置续推。方案还覆盖了网络断开、页面隐藏、浏览器崩溃等场景的恢复策略。
写了个插件让 Swagger 自动把后端下划线字段转成前端驼峰，顺便标清楚映射关系
Swagger 插件自动将文档中的蛇形字段名转为驼峰，并在描述里标注映射关系，解决前后端命名风格不一致的联调痛点。文章分析了现有手动维护或前端转换方案的不足，详细介绍了基于 SpringDoc 的实现原理，包括递归处理嵌套对象、参数和响应体，并讨论了边界情况与常见问题。
分库分表后，这几种全局 ID 方案到底谁更扛得住
在2024年分布式数据库场景下，基于时间序列的Snowflake变体（如百度UidGenerator、美团Leaf-segment）是性能与可靠性最均衡的高并发首选，号段模式QPS上限最高但扩容风险大。UUID和数据库自增主键分别因存储索引性能和可用性问题，不适合生产环境。文章通过压测数据和故障案例，详细拆解了各方案的工程陷阱、适用边界及决策树，并针对时钟回拨、号段浪费、分片均匀性等常见问题给出了具体解法。
写了一套前端错误监控系统后，才发现最难的不是捕获，是指纹算法怎么去重才不误判
错误监控系统的真正挑战不在捕获，而在聚合与去重。文章详解了从四类错误捕获、传输层缓冲策略到ClickHouse存储的完整链路，重点剖析指纹算法的核心矛盾：堆栈标准化需去除动态参数并还原source map，取前三帧生成SHA256指纹；message归一化则通过正则替换动态值为占位符。同时讨论了source map版本管理与安全风险，最终将错误分组从8300降至1200，有效抑制告警噪音。
客户端多模型并发：用滑动窗口 + 令牌桶扛住速率限制
多模型并发调用 API 时，单纯用 sleep 无法解决限流问题。文章提出三层速率控制方案：先区分并发上限（用信号量）和速率上限（用令牌桶），再用滑动窗口防止突发流量。核心是令牌桶控制平均速率，滑动窗口限制瞬时并发，两者组合才能稳定扛住 API 限流。针对多模型、TPM 限制和 429 响应，分别给出独立限流器、加权令牌桶和自适应降速的实现方法。
按时间分表后，路由算法怎么做到查热数据永远不进历史库
按时间分表后实现热数据查询不穿透历史库，核心在于路由层引入“时间窗口感知”机制。设计需从三层入手：路由层解析SQL识别时间意图并与配置的热窗口做区间判断；通过轻量级元数据表实时维护每张分表的时间边界与冷热状态；采用查询改写而非简单拦截，将跨冷热边界的查询自动拆分并路由至不同数据源。同时，索引设计需配合路由策略，并对跨窗口查询建立分级降级机制。
token 超限别急着改模型：一套自动拆分段续传策略的落地设计
一套“预估-拆分-续传”策略解决长文本LLM调用超限问题：用毫秒级保守估算替代精确计算提前判断；按句边界拆分并加入重叠锚点保持语义；通过system prompt注入位置感知实现续传；辅以自适应重试动态缩小分段。实测将300k token输入的处理成功率从60%提升至97%以上。
monorepo 接口文档别每次 commit 都全量生成，我们踩过的坑和现在的触发策略
从全量生成到按需触发，接口文档生成策略的核心在于声明式依赖图和文件指纹。通过 Turborepo 的依赖感知能力，结合 `turbo.json` 的任务声明和 `--filter` 差分计算，能将文档生成范围精确到受影响的服务，并利用远程缓存大幅减少重复计算，使 CI 耗时从 11 分钟降至 1 分 12 秒。