本文根据两个仓库共 809 条 Git 提交整理，记录这个博客从 2023 年 1 月第一次进入 Git 到 2026 年 10 月的完整演进：2023 年从零到可用；2024 年补齐七牛封面、登录封禁、评论审核与缓存；2025 年围绕评论系统深度重构；2026 年上半年引入 AI 问答与 AI 评论审核；7 月并入 total 聚合工程后，又经历了界面重做、自托管字体与图表、评论 AI 容错，9 月一轮集中的性能、可靠性治理和六套主题，以及 10 月接入炊想小程序的后台、重做后台界面、修掉一处存储型 XSS 并把前端重复实现合并成一份。
炊想上线头五天，三十来个陌生访客打开过，却没有一个人用上搭配，10 月 5 日之后也没有人再申请注册验证码。本文记录 2.0.16 怎么拆掉这道邮箱注册墙：按 Referer 里的版本段翻 nginx 日志找访客，以及日志看不到的盲区；用 openid 静默开游客，游客只是 rk_user 里多一个标记的普通用户；绑定邮箱复用注册接口原地转正，不迁移任何数据；注册防刷的两道上限改成只数正式账号；分享邀请双方各得 1 次；再补上埋点和拉新漏斗。
流式读取时，读超时量的是两段输出之间的间隔；同一个 Read timed out 可能是上游还没开始写，也可能是写到一半。记录怎么在 RestTemplate 里记下有没有输出、退避怎样和总时限一起算，以及用 MockRestServiceServer 和假时钟把这些分支测出来，附带一个营养素被写成英文数词的解析问题。
炊想小程序上线第一天，点一道新菜连续两次收到 504。排查发现：一份菜谱约 1600 个 token，上游每秒十几个，要写 90 秒；非流式请求的读超时实际等于「整份必须多少秒内写完」，75 秒必断，重试又等 75 秒，而 nginx 120 秒就替后端回了 504。本文记录改成流式读取（读超时只管两段间隔、另设总时限）、按「越靠近上游越先放弃」重排后端、nginx、小程序三道超时、晚失败不重试，以及上线后的真实耗时和 9 个模型的实测对比。
博客在六天里从一套样式变成了六套主题。第一版只叠了一张 1528 行的覆盖样式表，颜色换了、骨架没变，第二天推倒重来：每套主题一套独立模板，评论、表情、AI 助手等组件抽成共享片段，脚本一行不改。本文记录这套结构的划分与回退机制、Thymeleaf 片段选择器和 CSS 层叠带来的几个坑、去掉点击后的焦点框时要对付的 120 条规则，明暗切换的圆形扩散为什么在流萤上看不出来、又为什么一顿一顿，用无头 Chrome 做流畅度测试找到的几处主线程空转，以及不部署就在线上页面验证本地样式的方法。
发版时偶发的 502 往往不是代码抛出的，而是停机链条上某个环节没有接上。本文用 Spring Boot 2.7 与 Tomcat 9 做对照实验，以 SIGTERM 为零点记录进行中的请求、新连接、keep-alive 连接和 SSE 的实际表现，说明优雅停机只保护已进入应用的请求；再依次排查启动脚本缺少 exec 导致 JVM 收不到信号、timeout-per-shutdown-phase 并非硬上限、Kubernetes preStop 与宽限期的预算，以及 Nginx 对 GET 与 POST 重试行为的差异，最后给出长连接收尾、线程池等待和发版期间的验证方法。
一台 2 核 1.7 GB、出口约 4 Mbps 的服务器上跑着六个 Spring Boot 应用。本文记录一次先测量、后动手的全面体检：证书自动续期与每日备份，用 rsync 加可复现构建把发版上传从 50 分钟压到十几秒，把占文章页 85% 的内联脚本逐字节核对后外置，第三方前端库改用固定版本副本，归档页从 260 毫秒降到 40 毫秒，修正软 404 与扫描器噪音，并记录音乐版权误判的真实原因，以及测完内存数据后决定不做的取舍。
起点只是评论区的「博主」标签不见了，往下追却牵出了写放大 1478 倍的 binlog、一页 42 MB 的留言配图、跨五层嵌套的孤儿数据，以及同一个问题在代码里的四种答案。本文按排查顺序记录十四次改动的根因与取舍，包括两次把测量工具的毛病错当成站点故障的判断失误。
本文以多模型系统为例，指出付费大模型接入的关键不在接口调用，而在身份、模型、网络与成本边界。后端应建立统一出站层，集中完成认证校验、模型白名单、授权、端点验证及 Redis Lua 额度控制。Redis 异常时应拒绝付费请求，禁止自动重试和重定向；长连接使用租约心跳，结果不确定时不立即释放租约，避免重复计费。分享标题等隐式功能应固定使用免费模型并支持降级，以自动化测试固化权限、路由和异常处理规则。
本文记录了把四个独立的 Spring Boot 项目（chat、puke、zepp、blog）合并为一个 Maven 多模块工程，只启动一个 total‑app.jar 的实践。原先每个项目占用一个 JVM，导致服务器内存接近 96%；通过在根 pom 统一依赖、在 launcher 中用 SpringApplicationBuilder 依次启动四个 ApplicationContext，并将配置分别放在 chat.yml、puke.yml、zepp.yml、blog.yml 中，消除了 JVM 底座的重复开销，内存降至约 70%。文章重点阐述了类路径冲突、资源目录重名、自动配置串扰和日志全局化等踩坑及对应的统一依赖、资源隔离、spring.autoconfigure.exclude 等解决方案。部署时仅需一次打包并用单条 java 命令启动，端口和 Nginx 配置保持不变，运维更简洁。该方案适合资源受限、访问量不高且对隔离要求不强的场景，虽牺牲了故障隔离，但能显著降低内存压力，为小型服务器提供务实的优化路径。
文章围绕核心数据与增强数据的边界划分，讨论失败降级、超时控制、异步补偿、可信代理解析、私有地址处理以及本地 IP 库迁移检查等关键问题。通过统一“IP未知”状态，让系统在定位服务不可用时仍保持评论提交能力，同时保留内部监控和问题排查能力。最终实现一个可失败、可恢复、可观测的外部数据增强方案。
AI 评论审核真正的难点并不是调用大模型，而是如何让一个异步、不稳定、可重试的外部能力融入业务流程。本文以 Spring Boot 博客评论系统为例，介绍如何通过状态机、事务提交后回调、乐观锁式条件更新、失败分层重试、事务一致性和前端结果定位，构建可靠的 AI 评论审核链路。通过明确状态流转、防止过期任务覆盖人工操作、保证回复数据一致性，并完善用户侧反馈闭环，让 AI 功能从“能运行”提升到“可维护、可恢复、可上线”的工程化实现。
