一、项目目标
做一个个人/多人使用的网址导航站，核心用来存储：
- 自己常用的网站
- 网上收集到的有用网站
通过目录 + 标签两种方式组织，支持后续通过浏览器插件快速收藏网页。
二、功能需求
核心功能
书签/网址的增删改查
目录（Folder）管理：支持层级目录或扁平目录
标签（Tag）管理：支持多标签、标签颜色
搜索、排序、点击统计
书签自动抓取标题、描述、favicon
谷歌登录
多用户与共享
支持不同用户注册/登录
用户可以查看别人的公开导航
用户可以分享自己的导航栏目给别人
支持一键导入他人分享的导航
可以参考热门书签或者实现一个好用的书签定制化数据结构
可选：公开导航广场/发现页
外部接口（重点）
提供外部调用接口，用于写入/新建书签
目标：后续开发浏览器插件，实现一键快速打标签保存
接口需要鉴权机制（如 API Token）
三、技术要求
| 项目 | 你的要求 |
|---|---|
| 前端框架 | Next.js |
| UI 组件/样式 | 流行、好看、方便修改，倾向复用 GitHub 现成 UI/导航模板 |
| 后端协议 | tRPC |
| 数据库 | MongoDB |
| 认证 | 支持多用户，OAuth/Credentials + API Token |
| 部署方式 | 自托管，不使用 Vercel 等 Serverless 平台 |
| 容器化 | 倾向 Docker Compose 部署 |
四、设计/体验要求
- 前端风格现代、美观、易修改
- 参考/复用现有开源导航页模板或 Dashboard UI
- 支持响应式（PC + 移动端）
- 可考虑的参考项目：WebStack、Huntly、Taxonomy、shadcn/ui dashboard、littlelink
五、需要确定/讨论的问题
架构层面
- tRPC 与外部接口的兼容性：tRPC 默认不是标准 REST，浏览器插件如何最方便调用？
- 方案 A：插件内直接使用 tRPC client
- 方案 B：使用
trpc-openapi暴露 REST 端点 - 方案 C：tRPC 之外再单独建一个 REST API 层
- 前后端是否同仓库：
- 方案 A：Next.js 单仓库，前端 + tRPC API 一起部署
- 方案 B：前端单独一个仓库，tRPC 后端独立服务（考虑）
数据层面
- 目录是否支持多级嵌套？还是只支持一级目录？
- 标签是否全局共享？还是每个用户独立一套标签？
- 书签去重策略：相同 URL 不同用户可重复，同一用户内去重？
- 分享粒度：分享整个目录？分享单个书签？分享一组标签？
- 导入时冲突处理：重名目录合并还是新建？重复 URL 跳过还是覆盖？
功能层面
- 浏览器插件最小功能：
- 只保存当前页面 + 选标签？
- 还是需要弹窗选择目录/标签？
- 是否支持快捷键触发？
- 是否需要 AI 辅助：
- 自动提取摘要
- 自动推荐目录/标签
- 自动分类
- 是否支持以下增强：
- 全文搜索
- RSS 订阅/自动更新
- 书签快照/网页存档
- PWA 离线访问
复用层面
- 是否直接 Fork 现成项目改造？例如 Huntly 已具备书签管理核心能力，是否在其基础上改 tRPC + 换皮？
- 前端导航模板具体选哪个？需要列出候选并对比。
六、推荐的验证方向（你可以问其他 AI 的问题）
- "Next.js + tRPC + MongoDB + Docker Compose 自托管做导航站，架构是否合理？有什么坑？"
- "tRPC 如何给浏览器插件提供外部写入接口？trpc-openapi 是否是最佳方案？"
- "有没有现成的 Next.js 导航站/书签管理开源项目可以直接 Fork 改造？"
- "MongoDB 下书签、目录、标签、用户、分享的数据模型怎么设计最合理？"
- "自托管 Next.js 应用，Docker 部署、热更新、数据库连接、生产环境最佳实践是什么？"
- "浏览器插件（Chrome Extension MV3）调用自托管 tRPC/REST 接口保存书签，怎么设计最简洁？"