网站收藏夹功能开发，核心是把用户关注的内容与账号建立稳定关联，并提供收藏、取消收藏、列表查询和分类整理能力。若只要求同一浏览器内保存少量链接，可以使用浏览器本地存储；若需要登录后跨设备同步、收藏内容长期保留或在多个页面显示收藏状态，就应由服务端保存数据，并用明确的接口契约连接前端。
网站收藏夹功能到底要解决什么问题？
一个可用的收藏夹不只是页面上的一个星标按钮。它至少要回答三个问题：用户收藏的是什么、收藏记录属于谁、用户之后如何找到并管理这些记录。
- 收藏对象：优先保存业务内容的类型和唯一标识，例如文章、商品、课程或帖子，而不是只保存页面标题和链接。
- 所属用户：每条收藏都应关联用户身份。未登录用户可以暂存在本地，但不能直接写入其他用户的数据。
- 管理方式：支持收藏列表、取消收藏、分页、关键词筛选；有明确需求时再增加文件夹、标签、备注、排序和批量删除。
例如，内容详情页需要显示“已收藏”状态时，页面不能只根据按钮颜色判断。它应根据当前用户和当前内容查询真实状态。用户点击收藏后，服务端成功写入记录，接口返回收藏记录或已存在的记录，前端再把按钮更新为“已收藏”。这样刷新页面或更换设备后，状态仍然可以被重新确认。
哪些使用条件决定采用本地存储还是服务端接口？
| 使用条件 | 适合方案 | 需要注意的参数 |
|---|---|---|
| 只在当前浏览器保存，用户不登录 | localStorage 或 IndexedDB | 内容标识、保存数量、清理策略 |
| 需要跨设备同步 | 账号加服务端数据库 | user_id、target_type、target_id、创建时间 |
| 需要分类整理 | 收藏记录加文件夹或标签表 | folder_id、tag_id、名称长度、归属关系 |
| 需要公开分享收藏内容 | 收藏数据与分享资源分开设计 | 分享状态、访问权限、失效时间 |
本地存储适合轻量工具和未登录场景，但换浏览器、清理站点数据或更换设备后，收藏可能无法恢复。需要长期保存的项目应将数据库作为最终数据源。公开分享也不能因为“收藏存在”就默认开放，必须单独设计权限字段和访问接口。
确定收藏范围后，接口需要怎样约定？
下面是一套可落地的接口设计示例，属于项目实现时可以采用的契约，不代表某个现成平台已经提供这些接口。实际开发时，路由前缀、认证方式和响应包装可以按照现有项目规范调整，但请求字段、成功条件和错误含义应保持稳定。
收藏数据模型如何设计？
收藏主表可以包含以下字段：
| 字段 | 作用 | 建议约束 |
|---|---|---|
| id | 收藏记录唯一标识 | 使用数据库生成的唯一值 |
| user_id | 记录所属用户 | 不能为空，并建立用户索引 |
| target_type | 收藏对象类型 | 使用受控枚举，不接受任意字符串 |
| target_id | 业务内容唯一标识 | 与内容表的类型和编号对应 |
| folder_id | 所属文件夹 | 允许为空，并校验文件夹归属 |
| note | 用户备注 | 限制长度并过滤不必要的格式 |
| created_at | 收藏时间 | 用于默认倒序排列 |
数据库应增加 user_id、target_type、target_id 的联合唯一约束。这样同一个用户重复点击收藏时，不会产生多条相同记录。若系统允许同一内容收藏到多个文件夹，则唯一约束需要改为 user_id、target_type、target_id、folder_id；这属于业务规则，不能在开发后再凭感觉修改。
新增、查询和删除接口分别返回什么？
- 新增收藏：使用 POST /api/favorites，请求至少包含 target_type 和 target_id，可选 folder_id、note。对象存在且用户已登录时，新增成功返回收藏记录。首次创建可以返回 201；若记录已存在，则返回已有记录和“已收藏”状态，不重复插入。
- 查询列表：使用 GET /api/favorites，支持 folder_id、target_type、keyword、page_size 和 cursor 等查询参数。返回 items、next_cursor 和 has_more，避免一次加载全部收藏。
- 查询单项状态：使用 GET /api/favorites/status，并传入 target_type 和 target_id。返回 is_favorited、favorite_id，详情页可据此初始化按钮。
- 取消收藏：使用 DELETE /api/favorites/{favorite_id}。删除成功返回无内容或明确的 deleted 状态；如果记录已经不存在，项目应提前约定返回成功还是返回 404。
- 移动或修改：使用 PATCH /api/favorites/{favorite_id}，仅允许修改当前用户拥有的 folder_id 和 note，不允许通过请求体改写 user_id。
列表接口中的 page_size 应设置上限，例如最多返回 50 条，超出范围时按服务端上限处理或返回参数错误。分页推荐使用游标，特别是收藏数量较大且用户会持续新增记录的场景。返回内容还应包含必要的展示字段，例如内容标题、缩略图和内容状态；这些字段可以由服务端组装，也可以由前端根据 target_id 继续查询，但两种方式必须在接口文档中明确。
前端点击收藏后，如何确认状态真的更新了？
前端应把收藏动作当作一次有结果的请求，而不是单纯切换图标。页面加载时，先根据用户身份和内容标识调用状态接口；如果返回 is_favorited 为 true，就显示已收藏。用户点击按钮后，暂时禁止重复提交，发送新增或删除请求，只有收到成功响应后才更新图标、收藏数量和提示信息。
完整链路可以按下面的条件执行：
- 用户未登录：点击收藏时不发送写入请求，先展示登录入口；登录完成后回到原内容页，再重新查询收藏状态。
- 用户已登录且内容有效：发送新增请求；接口返回 201 或已存在的 200 结果后，将按钮设置为“已收藏”，并保存返回的 favorite_id。
- 用户重复点击或网络重试：服务端依靠联合唯一约束和幂等处理返回同一条记录，前端不新增第二条收藏。
- 用户取消收藏：使用 favorite_id 发起删除；收到成功响应后，将按钮设为“收藏”，列表中移除该记录。
- 请求失败：恢复按钮原状态，保留错误提示，不把前端的乐观状态当成最终结果。
如果接口返回 401，说明登录状态失效，前端应引导重新认证；返回 403 时，说明当前用户没有操作该记录的权限；返回 404 时，应区分内容不存在和收藏记录不存在；返回 422 时，通常代表 target_type、target_id 或文件夹参数不符合约束。错误响应最好统一包含 error_code、message 和可选 fields，前端才能根据错误类型采取不同动作。
文件夹、标签和搜索参数应该什么时候加入？
当用户只有几十条收藏时，按创建时间倒序排列通常足够。收藏数量增长后，再加入文件夹和标签。文件夹适合“工作资料”“待购买”“课程”等互斥或层级明确的分类；标签适合一条内容同时属于多个主题。两者不要用一个字段强行替代，否则后续会出现移动、筛选和权限关系混乱。
文件夹接口可以单独使用 POST /api/favorite-folders、GET /api/favorite-folders 和 PATCH /api/favorite-folders/{folder_id}。创建时校验名称不能为空、长度不超过设定值，并确认同一用户下不能出现重复名称。移动收藏时，服务端必须校验目标文件夹的 user_id 与当前登录用户一致。删除文件夹时，应提前决定其中的收藏是移到默认文件夹、变成未分类，还是随文件夹一起删除。
关键词搜索应明确搜索范围。若只搜索内容标题，接口参数可使用 keyword；若还搜索备注和标签，应在文档中列出范围，并为相关字段建立索引。排序可以提供 created_at_desc、created_at_asc 或 updated_at_desc，但不要让前端传入任意数据库字段名，以免造成不可控查询。
上线前怎样验证网站收藏夹功能可用？
先用两个不同账号测试同一内容：账号 A 收藏后，账号 B 不应看到账号 A 的收藏记录；账号 A 删除后，列表和详情页状态都应同步变化。再测试重复点击、刷新页面、分页加载、文件夹移动、失效登录和无效内容标识。
- 新增成功后，列表能找到对应内容，详情页再次查询返回已收藏。
- 重复新增不会增加记录总数，数据库唯一约束没有冲突异常。
- 删除成功后，状态接口返回未收藏，旧的 favorite_id 不能继续修改。
- 直接修改请求中的 user_id、folder_id 或 favorite_id 时，服务端仍按当前登录身份校验权限。
- 收藏数量达到分页阈值后，下一页游标有效，不重复返回上一页最后一条数据。
- 内容被下架或删除后，列表有明确的“内容不可用”状态，而不是返回无法解释的空白卡片。
因此，网站收藏夹功能开发的最小可靠方案是：确定收藏对象，绑定用户身份，建立防重复约束，定义新增、状态查询、列表和删除接口，再让前端根据接口结果更新显示。只有在跨设备、分类整理或搜索需求出现时，才继续增加文件夹、标签、备注和分享能力，这样既能满足核心收藏用途，也能避免接口参数和数据关系过早复杂化。
