32 · 后续路线：S3 与 Sentry 怎样接入才算真正完成#

当前六个阶段的业务源码已经形成学习闭环。本章是下一步规划，不是已经接入 S3、Sentry 的使用教程。本次只补齐教程和阅读站，没有新增外部存储、监控或真实服务配置。

1. 先按业务价值安排顺序#

这是建议实施顺序，不是新增一串依赖就算交付。每一步都要有输入、授权、失败处理和验收结果。

规划的数据流：选择文件 → 服务端检查团队和工单权限、类型与大小 → 生成受限上传资格 → 客户端传存储 → 服务确认元数据 → 授权下载 / 删除。

需要设计附件所属团队、工单、上传者、对象键、状态和大小；不能只接受浏览器自报“上传成功”，也不能把存储对象永久公开作为权限方案。

上传到存储与元数据写数据库跨系统，必须考虑失败补偿、未完成上传和孤儿对象清理。预签名地址有有效期，也仍要在签发前验证权限；对象键不能成为可猜到就可读取的凭证。

验收至少包括：正常上传 / 下载、超限拒绝、客户只访问自己的工单附件、跨团队拒绝、失效地址、重复确认、失败清理与删除一致性。具体 SDK 和供应商选型应在真正实施时对照其官方版本文档。

当前 CSV 是有上限的字符串，存 PostgreSQL 且 24 小时过期。未来可改为分批生成并写私有对象，账本只保留对象定位与元信息。

但租约、最初数据范围、执行 / 下载时重查权限、过期和幂等仍要保留。换存储不能顺便把鉴权下载改成无条件公开链接，也不能声称流式写入天然解决所有数据快照问题。

前端交互、Next.js 请求与独立 Worker 各有自己的生命周期。规划应包含初始化、部署环境与版本、source map、错误关联字段和可控测试事件，再决定哪些失败应触发通知。

需明确不发送 Cookie、令牌、数据库连接串、工单正文与 CSV 等内容。现有 Pino 日志是运行定位线索，不等于已接入 Sentry；将来两者协作，不必把全部日志都变成错误事件。

验收包括：受控前端异常、接口内部异常、Worker 最终失败能被定位；能识别相同发布版本与任务 ID；敏感字段没有上传；告警确实到达指定接收渠道。未完成真实验证前，不用一个空初始化文件冒充接入完成。

现状	后续工单应写清的验收点
共享表按服务显式过滤团队	新统计、搜索、附件和异步入口继续验证隔离
团队锁协调多种写操作	用负载与等待指标判断是否细化锁，不先猜瓶颈
草稿只在会话存储	若做云草稿，重新设计账号、团队、版本与冲突
轮询查询任务和回复	若做实时推送，仍保留权限、断线恢复与补读
Compose 健康不自动重启 unhealthy 进程	明确监测、通知与恢复职责

练习：增加“上传”按钮并返回一个固定成功地址，是否完成了 S3 接入？

动手练习查看参考答案

参考答案：没有。真实对象、资源归属、权限、文件校验、结果确认与故障清理都还不存在；当前项目明确把这些能力延后，不能用界面假动作替代业务闭环。

后续继续遵循同一学习方法：前端调用 → 接口校验与权限 → 业务处理 → 数据库与外部系统 → 可信结果与失败恢复 → 可复现验收。 本章完成标记仅表示你读完了规划，不表示任何外部服务已经接入。