机构内容发布平台技术规格

1. 系统目标

系统将机构首页、新闻、报告、团队、顾问、服务、合作伙伴和联系信息从静态页面迁移为可持续维护的内容平台，并区分公开读取与后台管理接口。

2. 逻辑架构

• Nuxt 前台：负责服务端渲染或静态生成、公开路由、SEO 和内容展示。
• Vue 管理端：负责登录、文章编辑、团队、合作伙伴、报告、联系与其他配置。
• Go API：分为公开应用和管理应用两个入口，共享新闻、报告、成员、页面、Banner、合作、文件与会话服务。
• 数据存储：Go 模型和依赖表明主要使用文档型数据库；文件服务单独处理上传资源。

3. 模块边界

公开域包括 Banner、页面、新闻、报告、成员、合作伙伴和联系信息。管理域在这些内容之上增加创建、编辑、排序、发布和资源上传。会话模块负责管理访问，文件模块为图片和报告资源提供独立入口。

Go 服务按业务目录组织模型与处理函数，并通过生成的路由文件连接两个应用入口。这种结构让公开查询和后台写入可以分别部署，同时复用领域服务。

4. 内容工作流

1. 编辑者在管理端创建新闻、报告或机构资料。
2. 图片经过上传与裁剪，文件服务返回资源标识。
3. 管理 API 校验内容并保存草稿、排序及发布状态。
4. 公开 API 只返回允许发布的字段和资源。
5. Nuxt 页面按路由获取内容，生成列表、详情与机构介绍。

5. 技术亮点

• 前台、管理端和 API 独立仓库，发布节奏与权限边界清晰。
• Go API 将公开应用和管理应用拆成两个命令入口。
• 后台服务模块与页面域基本一一对应，便于定位内容责任。
• Nuxt 适合需要被检索的报告与新闻页面，优于纯客户端渲染。
• 上传和裁剪被纳入正式内容流程，而不是手工替换静态资源。

6. 已知缺口

• 数据迁移、模式版本和内容审计记录没有完整保留。
• 富文本需要明确允许标签和资源策略，否则存在内容注入风险。
• 多个服务仓库可能是迁移或复制关系，需选择唯一主线。
• 自动测试数量很少，发布状态、资源删除和权限隔离缺少证据。

7. 重建验收标准

• 草稿、已发布、已撤回和定时发布状态明确，公开接口不会返回草稿。
• 新闻和报告具有稳定 slug、版本、发布日期和引用信息。
• 删除内容前检查资源引用，历史链接有重定向策略。
• 管理操作保留审计记录，公开与管理接口使用不同权限。
• 前台首屏、详情元数据、移动布局和无脚本基本内容通过检查。

8. 证据边界

Go 主服务有 78 次提交，Nuxt 前台有 34 次，Vue 管理端有 23 次，另有一次导入的服务副本。代码结构足以恢复主要内容域和部署边界，但缺少生产数据库、完整迁移与运行指标，不能确认所有历史内容和权限规则。