网站收藏夹功能开发的最小可用方案，是把“用户收藏了什么”记录为一条可管理的数据关系，而不是只保存一个标题或一串地址。对内容型网站来说，核心字段通常包括用户标识、内容类型、内容标识、收藏时间和收藏状态；核心操作包括收藏、取消收藏、查询列表和判断当前内容是否已收藏。若还需要分类整理，再增加收藏夹目录、备注、标签或排序参数。

如果网站中的内容有稳定的业务编号，应优先保存内容类型加内容 ID，这样内容标题、封面和状态变化时可以从内容表重新读取。只有在收藏对象是外部页面或没有内部 ID 时，才适合以规范化后的 URL 作为主要标识。以下设计适合需要登录、跨设备同步和服务端保存数据的网站；如果只是单机浏览器临时保存页面，使用浏览器本地存储即可，不必搭建完整接口。

网站收藏夹功能应该先实现哪些核心能力？

第一版不宜同时加入过多整理功能。建议先完成一条完整闭环：用户在内容详情页点击收藏，服务端校验对象和用户权限，写入收藏关系；用户再次点击时可以取消，进入收藏夹页面后能够分页查看并打开原内容。

基础功能与可选功能

收藏按钮通常需要三种状态：未收藏、已收藏和处理中。未登录用户点击时，可以跳转登录或弹出登录提示；已登录用户点击后，前端应等待接口结果再切换状态。接口失败时不要把按钮永久显示为成功，否则会出现页面显示已收藏、刷新后却没有记录的问题。

收藏记录应保存哪些参数？

面向站内内容时，一条收藏记录可以采用以下字段：

• id：收藏记录自身的唯一标识，用于查询、更新和删除。
• user_id：创建收藏的用户标识，由登录态或服务端会话确定，不能由前端随意指定。
• target_type：对象类型，例如文章、商品、视频或专题，用于区分不同业务对象。
• target_id：对象在对应业务表中的唯一标识。
• folder_id：所属收藏夹目录，可为空；不需要分类时可以暂不设置。
• note：用户备注，可为空，并应限制长度。
• created_at：首次收藏时间，用于默认按收藏时间排序。
• updated_at：目录、备注等信息最后变更时间。

如果收藏对象是外部页面，不能只保存用户输入的标题。建议保存经过规范化的 canonical_url，并根据产品需要保存标题、缩略图等快照字段。快照只用于列表展示，原页面失效、标题变化或访问权限变化时，仍应定义清楚是继续展示历史记录，还是标记为不可访问。

确定收藏流程后，接口契约应如何设计？

下面的接口名称是一个可落地的契约示例，不代表某个现有系统已经提供这些接口。实际项目可以使用不同路径，但请求字段、返回含义、错误状态和权限边界应保持同样清晰。接口应优先围绕“当前用户的收藏关系”设计，而不是让前端直接操作任意用户 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，但需要避免逐条查询造成性能问题。对于已下架内容，可返回状态为不可用并保留收藏记录；如果业务要求自动清理，则应通过明确的清理任务完成，不应在用户打开列表时隐式大量删除数据。

前端与服务端联调时应验证哪些场景？

至少应覆盖未登录、正常新增、重复点击、重复请求、取消后重新收藏、目标内容不存在、目标内容已下架、目录不存在、备注超长、无权限访问其他用户记录和分页边界。每个场景都要验证接口状态、返回字段、按钮状态和刷新后的最终结果。

1. 用户在详情页点击收藏，按钮进入处理中，接口成功后显示已收藏。
2. 用户刷新详情页，前端通过收藏状态接口或详情接口中的状态字段恢复准确状态。
3. 用户连续点击或重复提交时，数据库仍只有一条有效记录。
4. 用户打开收藏列表，按默认排序获得稳定结果，翻页后不会出现明显重复或遗漏。
5. 内容被删除或下架后，列表显示预先约定的状态，而不是让页面出现空白卡片或未处理错误。
6. 用户尝试修改不属于自己的收藏记录时，服务端拒绝请求，且不能通过修改参数绕过权限。

如果系统只需要简单的“保存内容”能力，先实现收藏记录、状态查询、列表和取消即可；如果用户有明显的内容整理需求，再加入目录、标签、备注和批量操作。只有在对象来源、重复规则、权限范围、分页参数和删除语义都确定后，网站收藏夹功能开发才适合进入前后端联调阶段。