Admin 管理端开发进展（阶段性小结）

这篇记录汇总 Admin 管理端目前已经落地的功能和实现思路，方便后续回看。

后端服务与接口

管理端基于 Express，默认监听 127.0.0.1:3201，从 .env 读取端口配置，只对本机开放。服务提供一组 REST API，覆盖文章的增删改查、构建触发与构建状态查询、友链管理、个人名片读写等，UI 所需的静态资源也由同一个服务直接托管。这样的设计让启动成本降到最低，npm run admin 跑起来就能用。

数据层的思路是以文件为中心。文章存放在 src/content/blog/ 目录，直接读写 Markdown 文件；友链和个人名片的配置写回 src/consts.ts，保证管理端与站点的数据来源始终一致。整个服务不引入数据库，也没有持久化中间层，改动即时反映到源文件，构建时一次性生成静态产物。

文章管理与构建流程

文章列表按文件名时间戳降序排列，和前台页面的排序逻辑保持一致。编辑界面把 Frontmatter 元数据和正文内容拆成两个独立区域，元数据、内容、预览三个标签来回切换，写作流程不容易乱。另有一个”修复中文加粗格式”的小工具接口，专门处理 Markdown 强调符号紧挨中文时渲染不正确的情况。

构建触发很直接：一键调用 npm run build，服务端通过子进程捕获输出，前端实时展示构建日志和最终结果状态。不需要离开管理端，就能完成”改内容 + 确认构建成功”这一步。

友链与名片管理

友链管理有独立的视图，左侧列表、右侧详情编辑，支持新增、更新、删除，每个字段都有基本校验，避免空值或格式错误写入配置。

个人名片是全屏表单加实时预览的布局。表单一侧填写姓名、简介、社交链接等字段，预览一侧同步渲染站点会展示的效果，保存后直接写入 src/consts.ts，下次构建时生效。UI 层面补了提示，误操作的代价比较低。

几点收获

这次开发让我意识到，本地工具对”启动即可用”的要求很高，额外的安装步骤或依赖很容易成为阻力。以文件为中心的数据层虽然简单，但 Frontmatter 的手工解析在多行值和数组字段上有明显的边界问题，后续换用 gray-matter 会更可靠。UI 上的列表、表单、预览三段式流程减少了不少上下文切换，这个结构可以继续保留。