19 · 按需要加入账号、历史记录和额度

本页为文字教程；视频与配套媒体仍以实际发布状态为准。

返回课程总览 · 返回模块

本课交付：必要数据功能与用户隔离测试

本课不要求每个首版网站都加入账户。先说明为什么需要：用户是否要跨设备继续编辑、保存多份初稿，或使用有成本的额度。若只是一次性公开演示，注册可能是无谓阻碍；若要长期保存与收费，身份与归属就成为必须认真维护的基础。

示范站逐步增加账户、任务历史和使用额度。它们应共享一份服务端事实，不能由浏览器自己决定某条记录属于谁、剩余多少次或是否已经扣减。以下模型是教学方案，实际字段需要与既有系统兼容。

跟做一：先写身份与资料的关系

至少区分用户、会话、生成任务、结果和额度记录。一个用户可以有多个会话与任务，一份结果关联明确任务，任务关联所属用户。登录之后仍需检查每次资源访问；知道任务编号不代表有权读取正文。

OWASP 的授权指南强调默认拒绝以及每次请求的权限验证。Authorization Cheat Sheet | OWASP 练习时，创建甲乙两个隔离测试账户，用甲的凭据请求乙的任务，确认在返回正文和文件地址之前就被拒绝。不要只检查前端列表没有显示乙的数据，因为直接请求接口仍可能越权。

跟做二：让历史记录有明确生命周期

决定保存原始事实、初稿、修改版、时间和模型配置中的哪些部分，以及用户如何删除。若用户编辑了结果，区分原始生成稿与当前编辑稿，不要悄悄覆盖而无法追溯。首版可以只保留必要历史，但必须与界面说明一致。

历史页面需要空状态、加载失败、登录失效与记录删除后的处理。退出后，不应继续从共享缓存向另一个账户展示旧结果。MDN 的 Cookie 文档介绍了安全传输与访问相关属性。Using HTTP cookies | MDN 这些机制有帮助，但会话撤销、私有缓存与资源授权仍要作为完整流程检查。

跟做三：定义额度实际计什么

你可以按成功生成、输入长度或其他明确单位计量，但应在使用前解释。先区分额度上限、已经确认的消耗、正在预留的用量和失败补偿。页面上的一个数字不能代替服务端账目，也不能在每次刷新时重新计算成免费次数。

设计时写出重复请求的规则：相同用户、相同 requestKey 对应同一任务，不重复预留；相同标识却换了输入，应拒绝冲突。不要用按钮禁用作为唯一保护，网络重试和脚本请求都可能绕过界面。为额度事件保留可核对标识，便于处理用户反馈。

跟做四：用事务保护内部变化

PostgreSQL 的事务文档说明可以把关联操作作为整体提交。Transactions | PostgreSQL documentation 对本项目，可以在短事务中核对可用额度、创建任务并预留用量；处理完成后再确认消耗，失败时按规则释放或记录待核查。外部模型调用通常不应长时间占着这段事务。

重点演练两个并发请求争用最后一次额度，确认不会同时超额。再模拟任务已创建但返回中断，用户重试时是否能找到原任务。若上游已经产生费用而本地结果未保存，不能凭感觉补扣或返还，需要按任务与上游记录核实状态。

跟做五：把删除与恢复纳入验收

用户删除历史后，列表和详情接口都应反映状态；账户删除则需要处理会话、任务、结果和进度等关联资料。某些账务记录可能有另行处理要求，应按你的真实业务与适用规则核实，不在本课凭空承诺所有系统立即清空。你能说明并实现的范围，才应写进产品。

测试使用明确的临时账户和自创内容，删除后检查旧凭据失效、旧任务不可读，其他用户资料保持不变。备份、日志与外部供应商的数据处理边界也要被记录，不能因为主表一行被删就宣布所有副本已经消失。

加练：用一笔额度预留追踪整个任务

在隔离测试数据中设定一个明确额度上限，同时发出两个不同请求争用最后一个可用名额。记录哪条任务被接受、哪条被拒绝、预留与确认记录是否一致。这里的额度只是测试条件，不是正式套餐价格或承诺。

随后让被接受任务失败，再按规则释放预留，确认重试使用原请求标识时不会再次扣减。界面可以显示数字，但验收需要读回服务端账目与任务条数。若无法解释每次变化对应哪个任务，就先修数据模型，不急着设计更多套餐。

另外模拟删除甲账户：确认相关历史与会话按约定处理，而乙账户的记录与额度不变。这个负面检查能防止清理代码把全表当成单用户数据，必须在可恢复的隔离环境执行。

独立作业：交付一份数据责任表

为每个模型写明创建者、读取者、修改者、删除条件与权威来源。提交正常使用、越权读取、重复扣减、并发限额、失败补偿和账户删除的证据。至少一次验证数据库或接口中的真实状态，不只截图页面提示。

最后重新审视是否值得在当前阶段加入全部功能。如果历史没有真实需求，可以推迟；但只要你已经接受用户资料，就必须承担相应归属与保护责任。功能可以按需增加，数据责任不能因为产品还小而省略。