重构于Vite
内容提要
作者在春节假期将原基于PHP的WordPress博客重构为纯前端博客，采用Vite 2.0、Vue 3.0、SSG和PWA以保留SEO并为团队提前踩坑。文中介绍了技术选型理由，以及Tailwind CSS、PostCSS、jsDelivr CDN、Node爬虫、Express服务端、GitHub Actions自动化部署和PWA离线应用等实践，最终在Vite 2.0正式版发布当天上线。
延伸解读
技术选型背后的权衡
作者放弃WordPress，选择Vite 2.0 + Vue 3.0 + SSG + PWA，核心是为了保留SEO并提前为团队踩坑。SSR方案因服务器成本高被排除，SSG成为折中选择；Hexo因模板千篇一律被放弃，Saber和VuePress因Vue 2或定位文档而不适用。最终基于vite-ssr/vite-ssg自建脚手架，体现了对Vue 3生态的执念与对新工具的前瞻性。
Tailwind CSS与PostCSS的实践反馈
作者最初对Tailwind的原子类写法持怀疑态度，但实际使用后认为“真香”。关键优势包括：延续CSS属性命名、支持tree-shaking（Purge后核心样式从6M降至24K）、可通过@apply组合复用、支持暗黑模式。同时用PostCSS Language + CSS Variable替代Sass/Less/Stylus，实现嵌套和变量，降低了预处理器依赖。
自动化部署与CDN的协同
项目托管GitHub，通过GitHub Actions实现CI/CD：合并到main分支触发构建，打包产物推送到gh-pages分支，同时部署到阿里云服务器。静态资源全部指向jsDelivr CDN，利用GitHub仓库自动同步，无需额外部署。作者提醒注意SSL证书更新、301重定向、history路由支持等迁移细节，并建议用PicGo管理图床。
PWA与CDN的兼容性问题
使用vite-plugin-pwa时，若vite.config.ts的base设为CDN地址，构建出的PWA manifest资源路径会读取错误，因为manifest不能走CDN。作者向插件作者反馈后，原版在v0.5.3修复了该问题。配置时需显式指定scope和manifest.start_url，并设置base选项以避免404。这提醒读者在CDN与PWA结合时注意路径配置。
Q&A
为什么选择用 Vite 2.0 和 Vue 3.0 重构博客？
作者选择 Vite 2.0 和 Vue 3.0 重构博客，一方面是为了提前开荒 Vite 2.0，为公司后续业务踩坑并提供技术选型帮助；另一方面，Vite 构建速度比 Webpack 快很多，且 Vue 官方团队大力推广，生态完善。同时，作者想尝试新技术如 Tailwind CSS、PostCSS 等，并享受从 0 到 1 搭建脚手架的过程。
重构后的博客如何保证 SEO？
重构后采用 SSG（静态站点生成）方案实现服务端渲染，解决 SPA 应用空 HTML 文档的问题。同时使用 gray-matter 和 @vueuse/head 为每个页面定制 title、description、keywords 等 TKD 信息，并注意 robots、链接语义化、减少死链、旧地址重定向等 SEO 优化措施。
博客的自动化部署流程是怎样的？
代码托管在 GitHub，通过 GitHub Actions 实现 CI/CD。配置分支 push 或 pull_request 触发自动构建打包，并部署到阿里云服务器。workflow 中配置了 secrets 变量（如 ACCESS_TOKEN、SERVER_SSH_KEY、SERVER_IP 等），打包后的文件推送到 gh-pages 分支，同时用于 CDN 和服务器部署。
为什么选择 Tailwind CSS 而不是传统 UI 框架？
作者选择 Tailwind CSS 是因为它延续 CSS 属性命名，需要自己写样式，避免依赖 UI 框架导致忘记 CSS；支持 tree-shaking，构建文件迷你（从 6M 降到 24K）；可通过 @apply 组合样式；支持暗黑模式。作者认为它并非开倒车，而是更方便地写 CSS。
静态资源如何通过 jsDelivr CDN 加速？
作者将静态资源（js、css、img）全部指向 jsDelivr CDN，只需将文件更新到 GitHub 仓库，就会自动同步到 CDN。在 vite.config.ts 中修改 base 路径为 CDN 地址即可。为避免源码过大，可单独创建 assets-storage 仓库存储资源，并使用 PicGo 图床工具方便上传。
重构后服务端技术栈有什么变化？
服务端从原来的 Nginx + PHP + MySQL 更换为 Node.js + Express，通过 PM2 守护进程运行在阿里云。第一版没有使用数据库，数据主要迁移到 GitHub 仓库。需要重新配置 SSL 证书、域名 301 重定向，并确保路由 history 模式支持。
