Appearance
JY 设计原理
一句话
数据库驱动的静态博客：管理端写库，公开站在构建时把内容烘焙成 HTML，线上零 Node 运行时。
为什么公开站要静态化？
| 考量 | 静态方案 | 动态 SSR |
|---|---|---|
| 服务器成本 | Nginx 托管文件即可 | 需常驻 Node/PHP |
| 性能与安全 | 无运行时攻击面 | 需维护依赖与补丁 |
| 单人博客流量 | 足够 | 过度 |
| 内容更新频率 | 低（发文章才构建） | 适合高频实时 |
本博客更新不频繁，用 构建时渲染 换 运行时简单。
为什么管理端不能静态化？
jy-admin 需要：
- 登录与 Session（
iron-session） - Server Actions 写 MySQL
- API 触发 GitHub
repository_dispatch - 实时编辑、分类标签管理
这些必须在 Node 进程 中执行 → 采用 Next.js Standalone + systemd + Nginx 反代。
为什么「保存」和「构建部署」分离？
| 操作 | 作用 | 不做什么 |
|---|---|---|
| 保存 / 保存草稿 | 写 MySQL | 不触发 GitHub Actions |
| 顶栏「构建并部署」 | 触发 deploy-jy-site.yml | 不改编文章本身 |
原因：
- 避免每次改草稿都跑完整 CI（慢、浪费）
- 构建失败不影响数据已落库
- 用户可攒多篇「待发布」后一次构建
文章状态语义
DB status | 管理端 UI | jy-site 是否展示 |
|---|---|---|
draft | 草稿 | 否 |
published | 待发布 | 构建后才会出现 |
archived | 已归档 | 否 |
UI 叫「待发布」强调：库里有、线上还没有，需点「构建并部署」。
安全边界
| 资产 | 存放位置 | 禁止 |
|---|---|---|
| DB 密码、SESSION_SECRET、GITHUB_TOKEN | 服务器 .env / GitHub Secrets | 提交 Git、打进 standalone 包 |
| SSH 部署私钥 | GitHub Secrets DEPLOY_SSH_KEY | 写进管理端数据库 |
| 管理端 | 仅 127.0.0.1:5174，Nginx 反代 | 公网直连 Node 端口 |
| 生产 Session | secure cookie，必须 HTTPS | HTTP 下登录态种不上 |
与常见方案的取舍
| 方案 | 本项目选择 | 原因 |
|---|---|---|
| Vercel 托管 admin | 未采用 | 自建 MySQL + 同一 VPS 更简单 |
| Docker Compose 全套 | 未采用（文档有模板） | 测试机资源有限，systemd 够用 |
| 保存即自动部署 | 已移除 | 用户要手动控制构建时机 |
jy-site 用 pnpm build | 禁止用于生产 | 缺搜索索引、sitemap 修补 |
Agent 决策树
改的是文章内容/UI？ → jy-admin
改的是博客前台样式/路由？ → jy-site
改的是 SSH/部署文档？ → docs/ops/
需要线上立刻看到新文章？ → 确认 status=published + 触发构建部署
只改了 .env？ → restart jy-admin，不必重 build admin 包