去年家里人查出慢性病之后我开始系统整理各种健康科普资料饮食、运动、用药提醒、体检报告解读东西越攒越多散的到处都是。公众号文章存了一堆链接短视频刷过就忘PDF躺网盘里再也没打开过。后来我想明白一件事我需要的不是收藏夹是一个能自己发布、分类、管理、搜索的内容站点于是就有了这个“个人健康科普知识分享管理网站”。技术选型上我用了 Node.js Vue没上 Spring Boot没买服务器之前先用本地开发跑通全流程前后端分离从零到一整套能用的东西前后大概花了两周业余时间。这篇博文就把整个过程中的需求拆解、技术选型、环境坑点、前后端设计、联调部署和后续扩展完整复盘一遍给同样想搭个人内容站、知识库或博客系统的朋友一条可以直接照抄的路径。1. 为什么搭一个“个人健康科普网站”需求拆解与功能边界1.1 个人内容创作者的真实痛点做个人站之前我先尝试过现成的博客系统WordPress、Halo、Hexo都试过。WordPress功能全但太重插件安全补丁追着打Hexo是静态博客发布要走 Git 流程对文章配图、临时改写特别不友好。更重要的是健康科普内容有一个特性信息需要持续修订。今天写的“血压测量注意事项”下周看到最新指南可能就得改静态站改一篇文章要重新构建发布很麻烦。我需要的是一个带后台管理、能在线编辑、发布即生效的动态站点。另外健康科普内容形态很杂日常碎碎念的备忘录、图文并茂的长文、带表格的对比资料、偶尔还想嵌入视频。这些放在同一个文章模型里就需要内容结构足够灵活。用 Markdown 做正文存储是最稳妥的方案渲染层可以自由控制样式排版不会像富文本编辑器那样满天飞。确定了“后台编辑 Markdown 前端渲染 分类标签 搜索”这套核心模型之后我直接把现成博客方案全部放弃决定自己写。1.2 功能清单与“不做清单”个人项目最大的问题不是功能太少是功能越加越多最后烂尾。我给自己定了严格边界要做的文章发布与编辑、分类和标签、全文搜索、文章详情页、评论点赞收藏、简单的后台登录、敏感词过滤、免责声明。不做的多用户注册体系、复杂角色权限、视频转码、实时消息推送、社交动态流。这份“不做清单”很重要。健康科普网站最大的争议点在于内容是否专业可靠而不是社交互动所以我把主要精力放在内容组织与内容安全上而不是搭一个热闹却没有人维护的社区。多用户体系听着高级但个人维护一个 UGC 平台要面临审核压力我还不如做单作者内容站访问者留言评论就行。功能清单确定之后技术上的核心模块就清晰了文章模块、分类标签模块、评论模块、搜索模块、后台管理模块。前端五六个页面后端五六个路由文件规模控制在一个周末能写完、一个晚上能排完错的范围。1.3 为什么选 Node.js Vue而不是 Spring Boot Vue这个选择我纠结过一阵子。Spring Boot Vue 是前后端分离的经典组合企业项目里遍地都是资料也多。但个人项目讲的是迭代速度和心智负担一个凌晨两点的 bugNode.js 的单语言栈排查起来比 Java 那套快得多。Node.js 的优势在于前端同学上手零门槛、npm 生态对内容站需求覆盖极好Markdown 解析、工作量微小但顺手、内存占用比 JVM 低很多跑在 1核2G 的入门服务器上完全没压力。Vue 我选 Vue 3 组合式 API个人觉得比选项式更适合中后台内容管理这类“逻辑复用强烈”的场景。至于为什么不选 Next.js 或 Nuxt因为个人内容站对 SEO 确实有需求但可以用“预渲染 Sitemap”的折中方案解决纯前后端分离的开发调试体验更简单别一开始就上全栈 SSR 框架不然部署环节会多出不少心智负担。2. Node.js 安装与项目脚手架这一小时最容易劝退新人2.1 Node.js 版本选型LTS 优先别追新很多人上来就装 Node 最新版结果一个包不兼容、另一个编译报错网上查也查不到其实问题就出在版本上。Node.js 的版本策略非常明确双数版本是 LTS长期维护单数版本是 Current尝鲜个人项目一律选 LTS。我用的版本是 18 和 20 过渡过来的到写文章时 20 已经完全稳了。安装时直接从官网下载 msi 包一路下一步即可。要注意安装路径里别带中文和空格我用的是D:\nodejs。装完先验证三个命令node -v npm -v where nodewhere node这一步很多人忽略如果输出结果里有多个 node 路径说明你机器上可能已经装过其他版本环境变量 PATH 顺序决定到底用的是哪个这往往是后续 “我明明装了新版为什么还是旧版” 的根源。如果以后要同时维护多个 Node 项目推荐装一个 nvm-windows切版本非常方便。个人站项目固定一个 LTS 版本就够了暂时没必要上版本管理工具省一层复杂度。2.2 “npm.ps1 无法加载”折腾我半小时根源是 PowerShell 执行策略刚搭项目那会儿我在 PowerShell 里执行npm create vuelatest直接弹出一行红字npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本。第一次遇到真的一头雾水网上搜到的解法五花八门有让改注册表的有让换 cmd 的还有让下载脚本覆盖的我后来才搞清楚根因。这是 PowerShell 的执行策略Execution Policy在拦截 .ps1 脚本默认的Restricted策略不允许运行任何本地脚本文件而 npm 在 PowerShell 下是通过 npm.ps1 这个脚本执行的所以直接被挡住。解法不是关杀毒、不是改文件而是手动放宽当前用户的执行策略Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserRemoteSigned的意思是本地脚本可以运行从互联网下载的脚本必须有数字签名。这个策略比Unrestricted安全得多日常开发够用也不会把系统完全裸奔。注意执行策略修改的是 PowerShell 本身跟 Node.js 无关。如果你换到 CMD 或 Git Bash 里跑 npm一般不会触发这个问题但很多前端工具链的脚本都是 .ps1建议一次性把执行策略改好省得以后装个包又炸一下。改完执行策略后关掉 PowerShell 重开npm 命令就正常了。2.3 用 Vite 创建 Vue 3 项目并整理目录结构项目脚手架我现在只认 ViteWebpack 配置写起来是真的折磨。创建命令如下npm create vuelatest health-siteVite 的 create-vue 脚手架交互式提问会让你选 TypeScript、Vue Router、Pinia、ESLint 等。个人项目我建议开 TypeScript虽然前期写起来多几个类型标注但文章列表、解析渲染这类数据处理场景类型能帮你少调试很多 bug。Pinia 建议先不开后面确实需要全局状态再手动加一个小项目没必要一上来就是全家桶。脚手架生成之后我会手动加一个清晰的功能分层目录src/ api/ # 所有接口请求封装 assets/ # 静态资源 components/ # 通用组件 router/ # 路由配置 stores/ # 状态管理后续需要再加 views/ # 页面组件 utils/ # 工具函数比如日期格式化、文本截断api 目录是我特别提醒的很多人喜欢直接在页面里fetch项目一复杂接口地址到处散落后端改个 URL 要全局替换。统一封装之后每个页面只关心调用哪个 api 函数后端起接口也清爽。3. Vue 前端架构路由、文章渲染与搜索互动3.1 路由设计的取舍静态路由够用别急着上动态路由很多 Vue 教程一讲就讲动态路由什么后端返回菜单、按角色生成路由表听着很高级。但个人内容站的页面是固定的首页、文章详情、分类页、标签页、关于页、后台管理页。这些用静态路由全部搞定完全没有必要让后端来控制前端路由结构。我的路由设计表是这样的路径页面说明/首页文章列表支持分页/article/:id文章详情根据 id 拉取正文/category/:slug分类页按分类筛选文章/tag/:slug标签页按标签筛选文章/search?q...搜索结果页搜索关键词/admin后台登录管理员登录/admin/dashboard后台管理文章发布、编辑、评论审核除了登录页和后台管理页所有前台页面都用路由懒加载const routes [ { path: /, name: home, component: () import(/views/Home.vue), }, { path: /article/:id, component: () import(/views/ArticleDetail.vue) }, // ... ]懒加载的收益在首屏尤其文章详情页带一堆 Markdown 渲染依赖没必要在访问首页的时候全量加载。还有一个细节是滚动行为SPA 切换路由默认不滚回顶部用户体验会怪怪的配置一下const router createRouter({ history: createWebHistory(), routes, scrollBehavior(to, from, savedPosition) { if (savedPosition) return savedPosition return { top: 0 } }, })这样用户从详情页返回列表页时能记住滚动位置从其它页面跳转则回顶部这是低成本高体验的一个点。3.2 文章详情页渲染Markdown 解析必须过 XSS 过滤健康科普文章内容里有大量格式需求各级标题、表格、引用、代码块比如每日摄入量计算器、图片。这些我用 Markdown 全部解决正文存原始 Markdown 字符串前端用markdown-it渲染成 HTML。但这里有个大坑Markdown 渲染出来的 HTML 如果不做过滤文章里内嵌一段script就能直接执行这就是 XSS 漏洞。个人站的流量虽然小但是健康科普内容容易被截图传播一旦被注入恶意脚本就成了传播链的一环。我的做法是渲染之后强制过一遍 DOMPurifyimport MarkdownIt from markdown-it import DOMPurify from dompurify const md new MarkdownIt({ html: true, linkify: true, breaks: true, }) function renderMarkdown(content) { const rawHtml md.render(content) return DOMPurify.sanitize(rawHtml, { USE_PROFILES: { html: true }, }) }注意linkify: true会自动把裸 URL 转成链接但也要配套处理javascript:协议。DOMPurify 默认会拦截这些危险协议我建议不要图省事关闭。文章正文的排版我直接用自定义 CSS 类没有引入大型 UI 库因为健康科普文章的排版需要大量定制小标题间距、引用块配色、表格边框UI 库的默认样式反而不伦不类。渲染容器宽度我限制在 720px 左右阅读体验最好。3.3 内容互动组件评论区、点赞收藏的模块化设计文章详情页需要三个互动模块评论区、点赞、收藏。这三个功能逻辑上是独立的但都依赖用户状态而且样式上都需要跟正文区风格统一。为了避免三个组件各自维护一套“当前用户是否登录”的判断我用一个小状态模块统一管理评论游客可以浏览登录管理员账号后可发发完先过一遍后端敏感词再到正文。点赞按 IP 每日限一次后端用一个哈希表去重。收藏把文章 id 存本地 localStorage作为私有的“稍后读”列表。互动模块全部用 Vue 插槽设计成可复用的列表项比如评论列表的每条评论是一个独立组件后续如果要加楼层回复直接在组件内部扩展不需要改页面级代码。这也是我推荐组合式 API 的原因点赞逻辑可以抽成一个useLike组合函数评论逻辑抽成useComments页面里只是把它们组合起来互相不污染。3.4 搜索与聚合展示分类、标签、全文搜索的联动分类和标签两个维度不能做成两棵独立的树否则用户在分类页想再按标签过滤就无处下脚。我的处理方式是列表页统一接收 URL 参数分类和标签只是参数不同/category/diet?tagweight-loss页面读取route.params和route.query拼成请求参数传给后端。页面里用一个filterBar组件展示当前分类下的所有标签点击标签只是更新 URL 参数组件复用性非常好。搜索则单独做一个/search页面防抖 300ms 调用搜索接口体验比提交表单再跳转顺滑很多。这里还应该注意空状态设计搜索结果为空时给用户推荐几个热门标签不要直接显示一片空白。4. Node.js 后端 API 设计接口规范、内容安全与搜索排序4.1 接口风格与工程目录组织后端我选 Express虽然 Koa 更潮一点但 Express 中间件生态更成熟出问题网上答案多个人项目求稳。工程目录同样按业务模块划分server/ app.js # 应用入口注册中间件和路由 routes/ article.js # 文章相关接口 comment.js # 评论相关接口 upload.js # 图片上传接口 auth.js # 登录/鉴权 controllers/ # 业务逻辑处理 models/ # 数据模型定义 middlewares/ # 鉴权、敏感词、错误处理中间件接口设计直接走 RESTful 风格下面是我实际的接口清单方法路径说明GET/api/articles文章列表支持分页、分类、标签参数GET/api/articles/:id文章详情POST/api/articles发布文章需要登录PUT/api/articles/:id更新文章DELETE/api/articles/:id删除文章GET/api/categories分类列表GET/api/tags标签列表GET/api/comments?article_idxx获取指定文章评论POST/api/comments发布评论POST/api/upload上传图片返回 URL关于数据存储我最开始用低门槛的 lowdb一个 JSON 文件数据库后来文章到几十篇、搜索需求一上来就换成了 SQLite。如果读者有 VPS我建议直接一步到位用 SQLite单文件、无额外服务、备份就是复制文件个人站完全够用。ORM 我用 Prisma虽然是 Node.js 生态里相对重的方案但 schema 定义清晰、迁移方便比我手写 SQL 靠谱。如果你不想引入 ORMbetter-sqlite3 也是不错的选择后者性能更好但需要自己写 SQL。4.2 健康科普内容的安全底线审核、敏感词与免责声明这是整个项目里我最看重的模块。健康科普内容跟一般技术博客不同它可能影响读者的健康决策一旦出错或者被恶意篡改后果不是删帖那么简单。所以我定了三层防线第一层发布权限。后端所有写操作必须带 JWT未登录一律不能创建内容。后台采用独立账号密码加密存储登录成功后返回一个有有效期的 Token写操作请求头带Authorization: Bearer token。第二层敏感词过滤。我整理了一个内科词库包括夸大疗效、绝对化表述“根治”“100%有效”以及各类人身攻击词汇发布和评论都过一遍中间件。命中直接拦截并提示修改。这个方案不够完美但作为个人站近实时拦截已经足够。第三层内容规范。每篇文章必须填写信息来源和参考文献列表前端渲染时强制展示“免责声明”卡片内容仅供科普参考不能替代专业医疗建议。这个设计不能省它不仅是法律风险规避更是对读者的基本尊重。我在后台编辑器的表单校验里就做了强校验参考文献为空不让发布。形式虽然简单粗暴效果很好。4.3 搜索与排序从 LIKE 到 FTS5以及热度权重搜索是内容站不可或缺的功能但我一开始草率用了LIKE %关键词%数据量稍微上来一点就慢得明显而且不支持中文分词“健康饮食”搜“饮食”没问题搜“健康食”就匹配不到体验不行。后来方案升级SQLite 自带的 FTS5 全文搜索。创建虚拟表、触发器同步更新查询用 MATCH 语法中文按“拼音分词 trigram”策略。虽然效果比 Elasticsearch 差了十万八千里但对几百篇量级的个人站来说体验完全够用而且零额外运维。排序方面我用了一个简单的热度公式hotScore views * 1 likes * 3 comments * 5 - ageDays * 0.8这个公式的思路很朴素阅读是弱信号点赞是中等信号评论是强信号时间衰减让老文章慢慢降温但不会沉底太快。新发布文章给一个初始加分避免出现“零互动 永远排不上去”的死循环。你可以根据自己的内容形态调权重比如教程站评论权重可以再高一点资讯站时间衰减要更狠。4.4 分类与标签的动态管理分类和标签的区别在需求里其实很明显但在数据模型里容易做成两张冗余表。我的做法是分类作为文章的一个必填字段关联独立分类表有层级标签则用独立的标签表和文章-标签关联表。发布文章时前端自动从正文中提取候选标签也可以手动输入。后台管理里做了一次“标签合并”功能把同义标签“高血压”“血压高”合并到一个规范标签下这样搜索和聚合展示不会因为口径不一而分散。5. 前后端联调阶段的坑CORS、历史路由与部署5.1 开发阶段的跨域Vite 代理比 CORS 顺手前后端分离开发时前端跑 5173 端口后端跑 3000 端口浏览器直接请求后端接口必被 CORS 拦截。很多教程让你在后端装cors中间件开发时全开、生产再限制这也能跑通但我不建议这么做。我的做法是开发阶段用 Vite 的 proxy 把/api转发到后端前端请求全部走同源后端不开启 CORS生产环境由 Nginx 做同源反向代理。Vite 配置// vite.config.ts export default defineConfig({ server: { proxy: { /api: { target: http://localhost:3000, changeOrigin: true, }, }, }, })这样做的好处是前后端代码里都不需要处理跨域逻辑“同源”贯穿开发到生产问题少很多。等哪天真需要第三方系统跨域调你的接口再在后端定向开启也不迟。5.2 登录态JWT 放 localStorage还是 httpOnly Cookie这是一个反复被讨论的问题。JWT 放 localStorage 的最大风险是 XSS 攻击能直接偷走 Token放 httpOnly Cookie 则天然免疫。但 httpOnly Cookie 需要处理 CSRF而且要后端配套设置 SameSite 属性。个人站权衡后我用了一个折中方案JWT 依然放 localStorage但是通过第一层 XSS 防护DOMPurify 前端内容一律不渲染未过滤 HTML将 XSS 面尽量缩小同时 Token 有效期只设 24 小时。另外一个很重要的细节是后台页面单独做了一个auth路由守卫每次进入 /admin 下的页面都检查本地 Token 是否存在且未过期过期自动跳登录页。但这个守卫只做前端拦截真正可靠的鉴权永远在后端接口层前端守卫只是用户体验优化。5.3 部署Nginx PM2以及 SPA history 路由的经典 404服务器选阿里云轻量或者腾讯云轻量均可2核4G 跑 Node 加 SQLite 绰绰有余。部署我用 PM2 管理 Node 进程Nginx 做静态文件服务和反向代理。先说 PM2很少有人第一次就配对pm2 start app.js --name health-site pm2 save pm2 startup三条命令分别完成启动、保存当前进程列表、设置开机自启。日志默认在~/.pm2/logs/下排错时经常要翻。Nginx 配置里最容易疏忽的是 SPA 的 history 路由。Vue Router 默认是 history 模式直接刷新/article/123Nginx 会去磁盘找这个路径找不到就 404。必须在 server 块里加上location / { root /var/www/health-site/dist; try_files $uri $uri/ /index.html; }这一行try_files把不存在的路径全部回退到 index.html让前端路由接管。后端 API 则单独配置一个 locationlocation /api { proxy_pass http://localhost:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }静态资源缓存也要配一下图片和 JS/CSS 分别设置不同过期时间减少后端压力。5.4 联调时最常见的三个二次坑第一个是图片上传跨域。开发阶段用 Vite 代理没问题但我在富文本里插入图片时发现编辑器的上传组件用的是独立 axios 实例没走代理的 baseURL导致图片传不上来。解决方法是所有请求统一走封装后的 api 模块不要有“散装请求”。第二个是端口占用。后端代码里写死了 3000但系统里有个服务偷偷占用了。排查命令netstat -ano | findstr :3000找到 PID 之后去任务管理器确认是不是自己的进程不是就杀掉或者换端口。个人项目端口随意但别在代码里写死多次出现的端口号用环境变量配置。第三个是 Node 进程崩溃但没有日志。PM2 默认 log 是区分 out 和 error 的有些人只看 out 找不到报错记得pm2 logs health-site把两条一起看。6. 后续扩展桌面端打包、小程序发布与内容运营节奏6.1 Electron 打包 Vue 项目的几个注意点内容站做桌面端的收益不一定大但我的确考虑过离线阅读场景研究了一下 Electron。本地开发完打包是另一个世界electron-builder的坑比想象中多图标尺寸、打包目录配置、主进程和渲染进程的通信方式。最简单的架构是主进程只负责创建窗口和加载静态页面渲染进程跑 Vue两者之间用 preload 脚本暴露window.api通过 ipcRenderer 和 ipcMain 通信。这里忍不住吐槽一下很多人问“Electron 主渲染进程 IPC 通信和 Vue 有关系吗”其实没有直接关系Vue 只是在渲染进程里跑IPC 是 Electron 自己的机制。如果你真的想让桌面端复用现有网站的业务接口直接把线上 URL 加载到 window 里是最快的方案只是功能受限、断网不可用。整体来说如果不去做桌面端特有的文件系统操作、全局快捷键之类的能力内容站真没必要上 Electron打包体积大、维护成本高收益不匹配。我做了一个原型之后就把这块搁置了先把网页端打磨好更实际。6.2 小程序发布健康科普类的资质门槛很多做内容的人首选小程序因为离微信用户近。但健康科普类小程序在微信生态的审核比较严格涉及“医疗健康”类目需要提供资质文件个人主体很难过。“个人健康科普”如果用“生活记录、经验分享”这种口径去报类目可能受限功能上也不能出现“问诊”“开药”等行为。如果想发小程序我建议使用 uni-app 来复用现有 Vue 代码。uni-app 兼容 Vue 3 语法H5 和小程序端共用一套业务代码图片路径、路由跳转、接口请求都有统一封装。但你要做好心理准备小程序的富文本渲染、Markdown 解析、评论组件在两端会有不少兼容差异打磨的时间成本不低于单独开发。对于一个小体量个人站我更推荐把内容同时分发到已有的内容平台公众号、知乎、小红书技术站只做“内容阵地”而非“分发渠道”。6.3 内容运营的技术支撑数据备份与更新节奏内容站最容易被忽视的是数据备份。我经历过一次数据库文件损坏之后现在的备份流程可以用惨痛总结每天凌晨用 cron 任务把 SQLite 文件和上传图片目录打包加密传到另一个对象存储桶保留 7 天。SQLite 单文件备份特别适合这种策略恢复时只需要把文件放回去。这个脚本我写完之后几乎没有再看过但每次想到服务器被误删都有底。更新的节奏也很重要健康科普内容讲究时效性尤其是用药、饮食指南等信息过时内容比没有内容更具误导性。我在文章模型里加了一个“更新时间”字段后台列表里对超过 180 天未更新的文章做黄色标记提醒自己定期复核。这就是技术对内容负责的一种具体形式。个人网站最有意思的地方在于它逼迫你像一个产品经理一样做减法又像一个内容编辑一样做把关。技术选型会变、框架会变但“把可靠的内容组织起来呈现给需要的人”这个目标不会变。我的体会是别等想清楚所有细节才开始先搭一个能用的骨架然后让内容去驱动后续的每一次优化。文章渲染慢就做缓存搜索不准就换分词分类不好用就合并标签——你的站你说了算这种掌控感很值得体验一次。