1. 模板 vs 工程：差在哪里？
很多项目一开始都是一个“能跑起来的页面”：一份 HTML，加上一些零散的 CSS 和 JavaScript，就可以对外展示。 但当你打算在这个基础上持续写文章、接入数据、做多环境部署时，问题就会开始集中爆发。
常见的几个信号：
- 任何改动都需要直接修改原始 HTML，难以复用结构。
- 静态资源路径混乱，本地、预发、生产环境经常不一致。
- 没有统一的构建与压缩流程，性能优化全靠“肉眼压缩”。
工程化的目标不是“炫技用多少工具”，而是让项目在 体量变大、参与者变多、生命周期变长 之后，依然可以被轻松维护与演进。
2. 选择合适的构建工具：为什么是 Vite？
本项目最终选择了 Vite 作为构建工具。原因很简单：轻量、开发体验好、静态站点支持足够友好。
在这个博客里，Vite 主要帮我们解决了几件事：
- 本地开发服务器与热更新（不再手动刷新 HTML）。
- 构建输出统一到
dist目录，方便对接 Nginx / Docker。 - 使用 Rollup 配置多入口 HTML，支持
src/views下的多页面结构。
2.1 为什么不是 Webpack？
Webpack 功能强大，但对于静态站点来说过于复杂。Vite 的优势在于：
- 开发速度：基于 ESM 的按需编译，启动速度极快。
- 配置简单：开箱即用的配置，减少学习成本。
- 生态兼容：基于 Rollup，插件生态成熟。
2.2 多页面构建配置
Vite 默认是单页面应用，但通过 Rollup 的多入口配置，可以支持多页面：
- 使用
getViewInputs()函数自动扫描src/views目录。 - 为每个 HTML 文件创建独立的入口点。
- 通过自定义插件将构建产物"拍平"到根目录，保持 URL 结构清晰。
3. 多页面结构：用目录来映射路由
对于博客这类内容型站点，多页面是天然需求：文章列表页、详情页、独立的 404 页面…… 与其在一个 SPA 里硬塞路由，不如利用静态站点的自然优势 —— 用目录结构映射 URL。
在本项目中，我们约定：
src/views/blog/index.html映射为/blog/。src/views/blog/xxx.html映射为/blog/xxx.html。src/views/404/index.html映射为/404/或 Nginx 兜底页面。
构建时，Vite 的 Rollup 配置会自动扫描 src/views，并通过自定义插件把这些 HTML "拍平"到构建产物根目录，从而得到干净的 URL。
3.1 开发环境的路由重写
开发环境下，Vite 的中间件会拦截请求，将 URL 重写到对应的 HTML 文件：
- 访问
/blog/→ 返回src/views/blog/index.html。 - 访问
/blog/intro-to-modern-frontend.html→ 返回对应的 HTML 文件。 - 访问不存在的路径 → 返回
src/views/404/index.html。
3.2 生产环境的 Nginx 配置
生产环境通过 Nginx 的 try_files 和 error_page 实现类似的路由逻辑：
- 先尝试匹配实际文件或目录。
- 如果不存在，返回 404 状态码。
error_page 404指令会捕获 404 并显示自定义 404 页面。
4. 布局与动效与"内容密度"的平衡
NeuralGlass 的视觉风格非常赛博：强烈渐变、动态背景、粒子特效。 如果直接把技术文章硬塞进原始模板，很快就会发现：酷是很酷，但并不好读。
处理这类问题的一个经验是：
- 在首页尽情展示视觉风格，强调"品牌感"。
- 在文章页收敛动画与对比度，优先保证排版与可读性。
- 通过局部玻璃拟态卡片包裹正文，让风格保持统一，但不打扰阅读。
4.1 样式抽离策略
为了保持代码的可维护性，我们将样式分为两部分：
- 公共样式（
src/css/common.css）：全局 reset、背景动效、Header、Footer、导航等通用组件。 - 页面样式（
style.css）：首页的 Hero、Features、Showcase 等区块，以及博客页面的专用样式。
这样，新增页面时只需要引入公共样式，再添加少量页面特定样式即可。
4.2 交互逻辑抽离
同样，JavaScript 也被抽离为公共逻辑（src/js/common.js）：
- 移动端菜单切换。
- 平滑滚动与导航高亮。
- 背景粒子与动效。
- 表单提交处理。
所有页面通过 index.js 统一引入公共逻辑，保持代码复用和一致性。
5. 部署与持续集成
工程化的最后一个环节是部署。本项目使用 Docker + Nginx 的方案：
5.1 Docker 化部署
Dockerfile 使用多阶段构建：
- 构建阶段：使用 Node.js 镜像运行
npm run build。 - 运行阶段：使用 Nginx 镜像，将构建产物复制到 Nginx 的静态文件目录。
这样既保证了构建环境的完整性，又最小化了运行时的镜像大小。
5.2 Nginx 配置优化
Nginx 配置需要注意几个点：
- 静态资源缓存策略：CSS、JS、图片等可以设置较长的缓存时间。
- HTML 文件不缓存：确保内容更新能及时生效。
- 404 页面处理：通过
error_page显示自定义 404 页面。 - Gzip 压缩：启用 Gzip 可以显著减少传输大小。
6. 小结：从"能跑"到"好维护"
如果你也正好有一个漂亮但难以维护的模板，可以从下面几个问题开始自查：
- 是否有统一的构建流程与输出目录？
- 路由结构是否与目录结构自然对应？
- 布局与动效是否为"内容服务"，而不是喧宾夺主？
- 代码是否具有良好的可复用性（样式、脚本抽离）？
- 部署流程是否自动化，是否支持多环境？
把这些问题逐步解决之后，你就会从"一个好看的页面"走向"一个可以长期演进的前端项目"—— 这也是这个博客未来持续更新的前提。
工程化不是一蹴而就的，而是一个持续优化的过程。随着项目规模的增长， 你可能会发现新的问题，需要引入新的工具或优化策略。但核心原则不变： 让代码更易维护，让流程更自动化，让团队更高效。
评论区