网站珍藏夹职能开发的最幼可用规划，是把“用户珍藏了什么”纪录为一条可治理的数据关系，而不是只保留一个标题或一串地址 。对内容型网站来说，主题字段通常蕴含用户标识、内容类型、内容标识、珍藏功夫和珍藏状态；主题操作蕴含珍藏、取缔珍藏、查问列表和判断当前内容是否已珍藏 。若还必要分类整顿，再增长珍藏夹目录、备注、标签或排序参数 。
若是网站中的内容有不变的业务编号，应优先保留内容类型加内容 ID，这样内容标题、封面和状态变动时能够从内容表沉新读取 。只有在珍藏对象是表部页面或没有内部 ID 时，才适合以规范化后的 URL 作为重要标识 。以下设计适合必要登录、跨设备同步和服务端保留数据的网站；若是只是单机浏览器一时保留页面，使用浏览器本地存储即可，不用搭建齐全接口 。
网站珍藏夹职能应该先实现哪些主题能力 ？
初版不宜同时参与过多整顿职能 。建议先实现一条齐全关环：用户在内容详情页点击珍藏，服务端校验对象和用户权限，写入珍藏关系；用户再次点击时能够取缔，进入珍藏夹页面后可能分页查看并打开原内容 。
基础职能与可选职能
| 职能 | 是否属于基础能力 | 合用前提 | 实现把稳点 |
|---|---|---|---|
| 新增珍藏 | 必须 | 用户必要保留内容供后续接见 | 服务端校验用户身份、对象存在性和沉复纪录 |
| 取缔珍藏 | 必须 | 珍藏关系允许用户随时撤销 | 只能删除当前用户自己的纪录 |
| 珍藏状态查问 | 必须 | 详情页必要展示“已珍藏”或“珍藏”状态 | 不要仅依赖锹剿按钮状态，应以服务端了局为准 |
| 珍藏列表 | 必须 | 珍藏数量超过少量纪录 | 使用分页、不变排序和内容状态处置 |
| 目录、备注、标签 | 可选 | 珍藏量较大，用户必要整顿内容 | 字段和权限会增长，适合在基础关环不变后参与 |
| 批量删除或批量移动 | 可选 | 用户时时整顿大量珍藏 | 必要限度批量数量，并明确部门成功或全数失败的规定 |
珍藏按钮通常必要三种状态：未珍藏、已珍藏和处置中 。未登录用户点击时，能够跳转登录或弹出登录提醒；已登录用户点击后，前端应期待接口了局再切换状态 。接口失败时不要把按钮永远显示为成功，不然会出现页面显示已珍藏、刷新后却没有纪录的问题 。
珍藏纪录应保留哪些参数 ？
面向站内内容时，一条珍藏纪录能够选取以下字段：
- id：珍藏纪录自身的唯一标识，用于查问、更新和删除 。
- user_id：创建珍藏的用户标识，由登录态或服务端会话确定，不能由前端轻易指定 。
- target_type：对象类型，例如文章、商品、视频或专题，用于分辨分歧业务对象 。
- target_id：对象在对应业务表中的唯一标识 。
- folder_id：所属珍藏夹目录，可为空；不必要分类时能够暂不设置 。
- note：用户备注，可为空，并应限度长度 。
- created_at：初次珍藏功夫，用于默认按珍藏功夫排序 。
- updated_at：目录、备注等信息最后调换功夫 。
若是珍藏对象是表部页面，不能只保留用户输入的标题 。建议保留经过规范化的 canonical_url，并凭据产品必要保留标题、缩略图等快照字段 ？煺罩挥糜诹斜碚故，原页面失效、标题变动或接见权限变动时，仍应界说明显是持续展示汗青纪录，还是象征为不成接见 。
确定珍藏流程后，接口左券应若何设计 ？
下面的接口名称是一个可落地的左券示例，不代表某个现有系统已经提供这些接口 。现实项目能够使用分歧蹊径，但要求字段、返回寓意、谬误状态和权限天堑应维持同样清澈 。接口应优先萦绕“当前用户的珍藏关系”设计，而不是让前端直接操作肆意用户 ID 。
| 操作 | 要求参数 | 成功了局 | 必要明确的规定 |
|---|---|---|---|
| 新增珍藏 | target_type、target_id，可选 folder_id、note | 返回珍藏纪录 ID、对象标识和创建功夫 | 沉复珍藏是返回已有纪录，还是返回矛盾谬误 |
| 查问列表 | page、page_size，可选 folder_id、target_type、order | 返回 items、分页信息和必要的内容提要 | 默认排序、最大页大幼和失效内容处置方式 |
| 查问单条 | 珍藏纪录 ID，或对象类型与对象 ID | 返回当前用户的珍藏详情 | 不能查问其他用户的私有珍藏纪录 |
| 更新珍藏 | 珍藏纪录 ID，允许更新 folder_id、note | 返回更新后的字段 | 未传字段维持不变，空值是否暗示断根 |
| 取缔珍藏 | 珍藏纪录 ID，或对象类型与对象 ID | 返回删除成功或当前已不存在 | 是否选取幂等删除，前端应能沉复点击 |
新增珍藏的要求能够抽象为：对象类型、对象 ID、可选目录 ID和备注 。服务端收到要求后，应顺次实现身份鉴别、参数体式校验、指标对象查问、用户权限判断和写入操作 。返回了局至少要让前端知路珍藏是否真正成功，以及后续取缔珍藏必要使用哪个标识 。
列表接口不应只返回珍藏纪录的 ID 。对于内容型网站，通；贡匾祷啬谌荼晏狻⑺趼酝肌⑻嵋⒅副炅唇印⒛谌葑刺驼洳毓Ψ 。若是这些展示数据来自内容表，接口层应处置内容已删除、下架或当前用户无权接见的情况，而不是让前端自行拼接数据库字段 。
沉复珍藏和取缔珍藏应该怎么约定 ？
推荐把“统一用户对统一对象只能有一条有效珍藏纪录”作为明确约束 。数据库层可对 user_id、target_type、target_id 成立唯一约束，利用层再将沉复要求转换为不变的业务了局 。这样即便用户急剧陆续点击，或移动网络导致要求沉试，也不会产生多条一样纪录 。
沉复新增有两种常见处置方式 。若是前端只必要一个确定了局，能够将其设计为幂等操作：已存在时直接返回原珍藏纪录，并象征为已存在 。若是产品必要提醒异常，也能够返回矛盾状态，但前端必须把该状态处置为“已珍藏”，不能当成系统故障 。取缔操作通常适合幂等处置：纪录存在就删除，不存在时仍返回当前已经取缔的了局 。
更新接口必要分辨“字段未传”和“字段传入空值” 。例如，未传 note 暗示维持原备注，传入空字符串才暗示清空备注；folder_id 为空可能暗示移出目录 。这个约定应写进接口文档并通过自动化测试固定下来 。
接口左券确定后，哪些数据库约束会影响使用履历 ？
珍藏职能看似只是增删数据，现实履历会受到索引、并发和内容读取方式影响 。对于站内内容，建议至少设置以下查问和约束：
- 对 user_id、target_type、target_id 成立唯一约束，预防沉复珍藏 。
- 对 user_id、created_at 成立列表查问必要的索引，支持按功夫分页 。
- 若是提供目录筛选，可增长 user_id、folder_id、created_at 的组合索引 。
- 列表查问必须限度 page_size，预防一次返回过多纪录 。
- 排序字段应来自允许列表，不能直接把前端传入的字符串拼接到数据库语句中 。
删除目录时也必要先确定战术 。若目录只是分类标签，删除目录能够保留珍藏纪录并将 folder_id 置空；若目录和珍藏纪录绑定，删除目录可能连带删除纪录 。前一种方式更适合用户已有较多珍藏的产品，后一种方式只有在产品明确把目录视为内容容器时才适合 。无论选取哪种方式，都应在接口了局和确认提醒中注明影响领域 。
珍藏列表读取内容时，能够选取关联查问，也能够先查问珍藏纪录再批量读取内容 。前者实现直接，后者更容易处置分歧 target_type，但必要预防逐条查问造成机能问题 。对于已下架内容，可返回状态为不成用并保留珍藏纪录；若是业务要求自动算帐，则应通过明确的算帐工作实现，不应在用户打开列表时隐式大量删除数据 。
前端与服务端联调时应验证哪些场景 ？
至少应覆盖未登录、正常新增、沉复点击、沉复要求、取缔后沉新珍藏、指标内容不存在、指标内容已下架、目录不存在、备注超长、无权限接见其他用户纪录和分页天堑 。每个场景都要验证接口状态、返回字段、按钮状态和刷新后的最终了局 。
- 用户在详情页点击珍藏，按钮进入处置中，接口成功后显示已珍藏 。
- 用户刷新详情页，前端通过珍藏状态接口或详情接口中的状态字段复原正确状态 。
- 用户陆续点击或沉复提交时，数据库仍只有一条有效纪录 。
- 用户打开珍藏列表，按默认排序获得不变了局，翻页后不会出现显著沉复或遗漏 。
- 内容被删除或下架后，列表显示预先约定的状态，而不是让页面出现空缺卡片或未处置谬误 。
- 用户尝试批改不属于自己的珍藏纪录时，服务端回绝要求，且不能通过批改参数绕过权限 。
若是系统只必要单一的“保留内容”能力，先实现珍藏纪录、状态查问、列表和取缔即可；若是用户有显著的内容整顿需要，再参与目录、标签、备注和批量操作 。只有在对象起源、沉复规定、权限领域、分页参数和删除语义都确定后，网站珍藏夹职能开发才适合进入前后端联调阶段 。
