网站珍藏夹功效开发的最小可用计划，是把“用户珍藏了什么”纪录为一条可治理的数据关系，而不是只生涯一个问题或一串地点 。对内容型网站来说，焦点字段通常包括用户标识、内容类型、内容标识、珍藏时间和珍藏状态；焦点操作包括珍藏、作废珍藏、盘问列表和判断目今内容是否已珍藏 。若还需要分类整理，再增添珍藏夹目录、备注、标签或排序参数 。
若是网站中的内容有稳固的营业编号，应优先生涯内容类型加内容 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，但需要阻止逐条盘问造成性能问题 。关于已下架内容，可返回状态为不可用并保存珍藏纪录；若是营业要求自动整理，则应通过明确的整理使命完成，不应在用户翻开列表时隐式大宗删除数据 。
前端与效劳端联调时应验证哪些场景？
至少应笼罩未登录、正常新增、重复点击、重复请求、作废后重新珍藏、目的内容不保存、目的内容已下架、目录不保存、备注超长、无权限会见其他用户纪录和分页界线 。每个场景都要验证接口状态、返回字段、按钮状态和刷新后的最终效果 。
- 用户在详情页点击珍藏，按钮进入处置惩罚中，接口乐成后显示已珍藏 。
- 用户刷新详情页，前端通过珍藏状态接口或详情接口中的状态字段恢复准确状态 。
- 用户一连点击或重复提交时，数据库仍只有一条有用纪录 。
- 用户翻开珍藏列表，按默认排序获得稳固效果，翻页后不会泛起显着重复或遗漏 。
- 内容被删除或下架后，列表显示预先约定的状态，而不是让页面泛起空缺卡片或未处置惩罚过失 。
- 用户实验修改不属于自己的珍藏纪录时，效劳端拒绝请求，且不可通过修改参数绕过权限 。
若是系统只需要简朴的“生涯内容”能力，先实现珍藏纪录、状态盘问、列表和作废即可；若是用户有显着的内容整理需求，再加入目录、标签、备注和批量操作 。只有在工具泉源、重复规则、权限规模、分页参数和删除语义都确定后，网站珍藏夹功效开发才适合进入前后端联调阶段 。
Android版
iPhone版