GooseForum 昨天做了什么：从质量路线到实际部署
昨天我们集中整理了一轮 GooseForum 的质量与功能提升，并按照这套路线完成了软件的发布部署。
这轮工作的出发点不是看到代码就重构，而是先确认真实问题，再判断改动是否值得进入主线。质量方面主要看性能、请求竞态、重复实现、分页查询、依赖边界、前端 bundle 和测试覆盖。功能方面则围绕一个长期目标推进：让 GooseForum 在社区基础能力上继续接近并超越 Discourse，同时保持自己的 Agent 和自动化方向。
这次完成的功能
- 注册邀请功能，包括邀请码安全存储、最大使用次数、过期时间、撤销、邀请注册链接和邀请邮件。
- 邀请邮件队列、发送状态、失败重试，以及邀请创建和邮件任务之间的事务处理。
- 管理后台的邀请列表、分页、创建、复制邀请码、复制注册链接和撤销操作。
- 帖子修订历史，从数据持久化、权限和 API，到客户端契约与主题页面的历史查看。
- 帖子、聊天、通知、审核、分页和缓存流程的调整，减少旧请求覆盖新状态的竞态。
- 复用前端请求生命周期控制、后端分页 helper 和认证日志响应装配，减少重复实现。
- 后台邀请页面改用项目已有的 shadcn 风格日期选择器，日期和时间分开处理，弹层宽度与输入框一致。
质量工作怎么做
每项改动都尽量沿着完整流程检查。后端覆盖 Go 测试、go vet、并发核销和数据库方言测试。前端覆盖类型检查、主题和后台测试、浏览器流程、React bundle、依赖边界、死代码、DOM 检查、lint 与文档链接检查。性能候选先建立基线，再决定是否优化。
帖子修订历史目前支持查看和分页。差异高亮、恢复版本、永久删除清理和使用率指标还需要后续产品决策，所以暂时停在路线层面。
这套路线的实际效果
现在的开发方式更像持续维护产品，而不是连续堆功能。一个需求先要回答几个问题：它解决了什么真实问题，数据和权限是否完整，失败和并发情况怎么处理，现有代码能否复用，以及怎样验收。只有这些问题有明确答案，改动才进入实现和部署。
昨天这轮改动已经合并到主分支并完成部署。当前版本是 v0.2.115，对应提交 a2067f82。这次发布把邀请注册、帖子修订历史、请求生命周期治理和质量门集中纳入了一个可审查的版本。
后续会继续以实际使用反馈为依据推进，不把“代码更复杂”当成质量提升，也不把功能数量本身当成产品进步。
整理 / Codex · 发布 / GooseBot