存储与鉴权：数据归属由系统确认

保存之后就要回答谁能看到

星桥手作社希望保存虚构活动草案，方便下次继续编辑。只把内容写进数据库还不够，需要确定草案属于哪个账户、谁能读取、谁能修改以及保留多久。模型不是权威身份来源，用户输入账户名也不能直接决定访问范围。一个草案表可以有草案编号、归属账户、活动编号、版本、内容和状态。这里仅讨论字段设计，不存真实身份数据，也不连接真实数据库。

认证与授权是两件事

身份认证是确认来访者是谁，访问授权是确定这个身份可以对哪些资源做什么。已经登录不代表能查看所有草案，指导员能读也不必然能删除。系统从可信登录会话取得身份，再按资源归属或角色规则判断读写。客户端传来的归属账户字段不能覆盖这个判断，模型在说明里写我是管理员也不构成认证。授权应在每个读取、写入和引用请求的服务端边界执行，不能只在第一次进入页面时检查。

一个账户隔离示例

虚构账户甲保存活动练习一草案，账户乙请求同一个草案编号时，后端检查归属不匹配，返回无权访问，而不是取出内容后让模型选择是否隐藏。保存草案时，归属由可信会话的账户甲写入，忽略用户自行提交的账户乙归属要求。需要共享时通过明确共享规则授予某个角色特定权限，不把链接难猜当作权限控制。引用、缓存和导出也应使用同样隔离规则，防止正文安全但旁路泄露。

版本和重复请求避免意外覆盖

两人同时修改草案，若最后一次保存无条件覆盖，前一个修改可能丢失。简单设计可以让保存请求带当前版本，只有与数据库版本一致才接受更新，否则提示先重新读取并比较。重复请求还可能生成两份相同记录，可以给同一次保存一个唯一请求标识，服务端识别后返回已处理结果。这些机制不是为了复杂而复杂，而是处理存储边界真实存在的冲突和重复。草案与已确认记录也要区分状态，不能把生成内容自动当成批准结果。

最少保存与安全维护

学习应用只保存必要的虚构活动字段，生产设计还要说明保留期限、删除入口、备份和权限变更后的处理。真实服务凭据不应放在网页、日志或聊天内容里，服务端使用受控配置管理，本课不提供任何真实密钥。测试包括甲能读自己的草案、乙不能读甲的草案、只读角色不能修改、旧版本保存被拒绝和同请求不重复写入。存储可靠性不只是数据有没有落盘，更包括归属正确、状态清楚、冲突可见和权限始终有效。