这一个月到底做了什么#

表面上看，是完成了六个相对独立的部分：

1. 服务器和服务运行环境。
2. 统一登录与权限管理的 SSO。
3. 统一对象存储入口 OSS Hub。
4. 跨框架共享的主题库。
5. 原生组件库和 Vue 组件库。
6. 可以承接不同网站的 Astro 项目模板。

但它们真正的价值不在“项目数量”，而在于彼此之间开始形成关系。

以后新网站不需要重新决定“账号怎么办、图片放哪里、主题怎么切、按钮长什么样、博客和文档怎么写”。这些问题已经有了默认答案。

先有一个能长期运行的地方#

服务器是最不容易在截图里体现、但最先需要稳定下来的部分。

只有本地项目时，启动服务很简单；当多个站点和后台真正上线后，域名、HTTPS、反向代理、环境变量、持久化数据、日志、备份和升级都会变成长期问题。

这部分工作没有直接增加任何页面，但它决定了后面的 SSO、OSS 和网站能不能成为持续使用的服务，而不只是开发目录里的 demo。

我不希望每做一个项目，就重新临时找一个部署方式。服务器整理完成以后，新的服务至少有了明确的运行位置和接入方式。

SSO：不再给每个项目重复做账号系统#

当计划中的网站越来越多，最不能接受的就是每个项目维护一套用户、登录、角色和权限。

所以先做了个人 SSO，把 OAuth2、OIDC、PKCE、JWKS、用户组、角色、权限、应用管理和审计放在一个系统里。

业务系统只需要关心：

• 当前用户是谁。
• token 是否可信。
• 用户是否拥有当前业务权限。

登录、安全策略和账号管理不再由每个网站从头实现。

这不只是节省代码。统一身份意味着以后作品站、论坛、资源后台和游戏入口可以逐渐形成连续体验。用户在不同站点之间移动时，仍然属于同一个生态，而不是进入互不认识的几套系统。

OSS Hub：让资源也有统一入口#

账号统一以后，第二个不断重复的问题是图片、视频、音频和构建产物。

对象存储本身已经很好用，但多个 Bucket、多个云服务和不同项目各自接入，会让资源管理越来越分散。OSS Hub 做的事情，是在对象存储之上补一层真正适合日常使用的工作台：

• 统一管理不同云存储配置。
• 浏览器预签名直传。
• 大文件分片上传。
• 文件索引、搜索与标签。
• 团队和 Bucket 权限。
• 远端对象与数据库索引对账。

以后图集站的原图、作品站的截图、游戏入口的封面、博客的媒体资源，都可以使用同一套资源基础，而不是散落在项目 public 目录和不同控制台里。

主题库：先统一规则，再统一页面#

以前保持视觉一致，主要依靠“照着之前的页面写”。这种方式在一个项目里还可以，跨多个框架后一定会逐渐漂移。

主题库把真正应该共享的部分提取出来：

• 主题色和色阶。
• 成功、信息、警告、错误状态色。
• 明暗模式。
• 字体、圆角、边框和阴影。
• 主题状态读取、保存与切换。

它不负责某个页面怎么布局，只负责告诉所有项目同一种绿色、同一种卡片圆角和同一种暗色背景应该是什么。

这一步很重要。视觉一致不能靠每次开发时“尽量做得像”，而应该让基础值来自同一个依赖。

组件库：让规则变成可以直接使用的控件#

只有 Tokens 还不够。按钮、输入框、弹窗、通知、标签页和内容提示仍然会重复实现。

因此主题库之上又有了两种组件形态：

• 原生 JavaScript Web Components，可以直接在 HTML、Astro、Markdown、Vue 或其它框架中使用。
• Vue 组件，服务需要 Vue 组合能力和现有 Vue 项目的场景。

原生组件库对我尤其重要，因为内容本身也可以使用组件。

在 Markdown 的翻译词条或文章里直接写 <m7-button>、<m7-alert>，不需要让整篇内容绑定 Vue 或 React。以后即使页面框架不同，内容里的组件标签和视觉规范仍然可以延续。

这也是为什么我没有只做一个 Vue 组件库。我要解决的是多个项目和多种技术之间的复用，而不是只优化某一个框架里的开发体验。

项目模板：终于把这些基础接到页面上#

主题和组件发布以后，还缺最后一层。

新建项目时依然需要处理：

• Header、Footer、首图和响应式布局。
• Astro 页面与 Vue Island 的边界。
• 多语言页面生成和缺失翻译回退。
• Axios、Toast 和取消请求。
• 文档、发布内容、搜索、SEO 和 RSS。
• 页面过渡和客户端生命周期。
• 评论、音乐、Live2D、Spine 等可选功能。

astro-temp 就是把这些能力接成一个可以直接开发页面的起点。

它最初越来越像原博客的复制品，后来才重新确定边界：保留视觉和交互规则，把博客专属内容变成可替换配置、布局插槽和可选 Feature。

现在它可以直接拿来做博客，也可以关闭发布能力去做作品站；可以保留 Docs 做产品文档，也可以只使用页面壳层和组件；需要音乐或看板娘时再开启，不需要时不会加载运行时和模型。

为什么花这么多时间做“开始之前的工作”#

基础建设很容易陷入一个问题：永远觉得还缺一层，永远不真正开始做产品。

这个月里我也多次遇到这种感觉。修完一个主题问题，会发现组件要同步；组件可以使用后，又发现模板没有统一入口；模板有了页面，还会继续出现多语言、子路径部署、页面过渡和资源版权问题。

但这些工作并不是完全没有边界。

现在已经有了一个可以停下来的节点：

• 身份有统一入口。
• 资源有统一入口。
• 视觉有统一规则。
• 控件有跨框架实现。
• 新网站有可运行模板。

剩下的功能可以在真实项目中按需要继续演进，不必再等一个“绝对完整”的基础设施版本。

接下来要做的个人生态集群#

下一阶段终于可以把重心从基础层移到具体网站和页面。

计划中的站点包括：

• 作品展示站，用来整理真正完成的项目和设计过程。
• 图集浏览站，用来承载插画、截图和高质量媒体浏览。
• 游戏论坛，形成内容、讨论、账号和社区关系。
• 网页游戏入口站，把游戏、活动、公告和账号连接起来。
• 继续保留博客、文档、新闻和更新日志，记录整个生态的变化。

我希望它们最终不是一组域名相近但彼此无关的网站，而是一个个人生态集群：

• 共享身份，但各自拥有合适的权限和业务边界。
• 共享资源基础，但由不同页面按照自己的方式呈现。
• 共享主题与组件，但不是复制同一个页面布局。
• 共享工程质量，包括多语言、SEO、移动端和可访问性。
• 可以从一个站点自然进入另一个站点，并保持连续的视觉感受。

统一不等于所有页面完全一样。

作品站应该突出项目，图集站应该让图片成为主体，论坛应该优先保证阅读和讨论效率，游戏入口应该更强调状态和进入体验。主题、控件和身份可以一致，但信息架构必须服务各自的目标。

给下一阶段定几个限制#

基础建设告一段落以后，我希望后面的开发遵守几个限制：

1. 新项目先做真实页面和主要工作流，不再先扩展基础库。
2. 只有两个以上项目真正重复的能力，才继续下沉到主题、组件或模板。
3. 重功能保持可选，不为了“模板看起来完整”默认全部开启。
4. 站点保持同一种视觉语言，但允许为内容和人群形成自己的版式。
5. 外部图片、模型、音乐和字体在上线前明确版权与分发边界。
6. 以后再把完整模板拆成 CLI，不让 CLI 设计阻塞实际网站开发。

这些限制是为了提醒自己：地基的目的不是继续研究地基，而是让上面的东西更快、更稳地长出来。

写在最后#

这一个月最明显的成果，不是某一个页面，也不是某一个 npm 包。

真正的成果是从“每次做一个独立项目”，走到了“可以持续构建同一个个人生态”。服务器、SSO、OSS、主题库、组件库和项目模板分别解决一类长期重复的问题，也开始形成清晰的上下游关系。

现在再创建一个网站，终于不需要从空目录开始，也不需要复制一份旧项目再小心删除不需要的部分。

接下来可以把时间花在更具体的事情上：作品怎样展示，图片怎样浏览，社区怎样组织，游戏怎样被发现和进入，页面怎样真正让人愿意使用。

一个月的基础建设到这里先告一段落。

终于可以开始做网站了。