Go 扩展（P2）
本页对应 SEO 计划中的 P2：Extending with Go。它面向「要在生产里长期维护」的扩展方式。
什么时候必须上 Go
Section titled “什么时候必须上 Go”优先考虑 Go 的典型信号：
- 计算/聚合很重：排行榜、复杂统计、批处理
- 要接入成熟基础设施：消息队列、可观测性、指标、链路追踪、灰度发布
- 需要更强的可测试性：核心业务规则希望有稳定的单测/基准测试
- 对性能与资源敏感：高 QPS、低延迟、内存可控
如果只是「轻量校验 + 少量业务胶水 + 自定义接口」，通常 JS hooks 更快更灵活（见下一页）。
扩展形态（PocketBase 常见 3 类）
Section titled “扩展形态（PocketBase 常见 3 类）”- 直接修改/编译 PocketBase（Go）
- 适合：深度定制、需要引入 Go 依赖、对生命周期/性能强控制
- 成本：升级 PocketBase 时需要重新集成与回归测试
- 外挂服务（Go/其他语言）
- 适合：团队已有服务体系、需要独立伸缩/部署
- 模式：PocketBase 作为 Auth + CRUD，服务负责重逻辑
- PocketBase hooks（JS）
- 适合：快速迭代、BFF/轻量 API、定时任务、自动化
推荐的工程组织（可长期演进）
Section titled “推荐的工程组织（可长期演进）”internal/：业务核心（纯逻辑，易测）pkg/：可复用包（必要时对外）cmd/pocketbase/：入口（注册 routes/hooks/commands）cmd/worker/：可选，异步任务/cron（若不想依赖 PB 的 cron）
关键原则：不要把业务写进 handler。handler 负责解析输入、调用 domain、返回响应。
生产要点（强烈建议）
Section titled “生产要点（强烈建议）”- 所有密钥来自环境变量或密钥系统（不要写死）
- 外部调用统一超时与重试策略（并可配置）
- 写入尽量用事务（PocketBase 的
runInTransaction/ DB transaction） - 统计类写入尽量隔离到独立集合（本项目已将插件 stats 放在
plugin_stats里）
- 关键路径：请求耗时、错误率、队列堆积、外部依赖耗时
- 将关键任务（例如 release sync）做成可追踪的「一次执行」记录（便于审计）
与本项目的关联
Section titled “与本项目的关联”本仓库当前的生产实现以 PocketBase + JS hooks 为主：
apps/backend/pb_hooks/：自定义 Routes、限流、同步 GitHub releases、Newsletter 邮件- 需要 Go 时建议把 重计算/高并发 的部分迁到独立 Go 服务，再由 hooks 调用或写回 PB。
如果你希望我继续把某些模块（例如：更复杂的搜索/聚合、评论反垃圾、统计离线聚合）用 Go 服务落地，我可以按这个结构补齐并提供部署方式。