1. 项目概述与设计初衷

1.1 这个标题到底说的是什么

“weixin105文章管理系统”，第一眼看上去像是个内部项目代号，但拆开来看，其实是一个非常典型的内容管理需求：一套面向个人或小团队的公众号文章管理方案。weixin105这个编号，我推测是项目在某个服务器上的部署目录或版本迭代代号，不重要，重要的是它背后代表的那类需求——很多人手里攒了大量文章素材、草稿、已发布内容，散落在各个编辑器、聊天记录、本地文件夹里，时间一长，想找一篇几个月前的文章，翻半天翻不到，想统计自己发过哪些主题，完全没有头绪。

这篇文章，就从我实际做过的一个类似项目出发，聊聊怎么从零搭一套轻量的“文章管理系统”。它不是要跟企业级CMS比功能，而是要解决一个很具体的痛点：个人创作者或小团队，需要一套能管得住文章、查得到历史、找得到素材的轻量系统，最好部署简单、上手不难、后续还能扩展。

1.2 适用人群和场景

先说说这套系统适合谁。

第一类，个人公众号运营者。一个人管一个号，文章产出量可能一周几篇，但积累一年就是上百篇，如果没有系统管理，想做个合集、想统计某个专题的产出，全靠人脑记忆，非常痛苦。

第二类，小团队的内容小组。两三个人一起维护一个内容账号，需要分工协作、审核流程、版本留存，这时候一套共享的文章管理系统就很有价值。

第三类，有点技术基础但不想折腾的人。这套方案的技术栈非常主流，不管是用PHP系的WordPress风格，还是用Python系的Flask/ Django风格，或者干脆用Node.js写个轻量服务，都有成熟的轮子可以借鉴。

1.3 它能解决什么问题

我把它解决的问题分成三个层面：

• 存储层：文章不再散落在各个地方，统一入库，带标题、标签、分类、状态、发布时间等元数据。
• 检索层：支持按标题、标签、分类、日期范围搜索，几秒内找到历史文章。
• 流程层：从草稿、待审核、已发布、已下线，完整生命周期管理。

听起来是不是很简单？但所谓“文章管理系统”，核心从来不是技术多复杂，而是这套系统的使用者能不能坚持用它。所以我的设计原则一直是：能少一步操作就少一步操作，能自动化就自动化，界面丑一点没事，但流程必须顺。

提示：如果你只是自己一个人用，别一上来就追求“微服务”“前后端分离”“容器编排”，那是在给自己挖坑。先用最简单的方式跑通流程，等痛点出现了再升级，这是个人项目活下去的关键。

2. 方案选型与技术栈拆解

2.1 为什么不用现成的CMS

很多朋友会说，市面上现成的CMS一大堆，WordPress、Ghost、Halo、Typecho，随便装一个不就行了，为什么要自己写？

我的回答是：看需求匹配度。

• WordPress功能太强大，插件系统丰富，但正因为太丰富，安全更新、插件兼容、主题维护这些事会慢慢消耗你的精力。而且如果你的文章来源不是WordPress后台，而是公众号后台、飞书文档、本地Markdown文件，那就需要一个“搬运”环节。
• Ghost很优雅，但它是为“从零写文章”设计的，内容导入导出能力相对有限，对中文公众号生态的支持也比较薄弱。
• Halo和Typecho在国内社区很流行，部署也很方便，但它们的定位更多是“博客”，而不是“文章资产管理”。

“文章管理系统”和“博客系统”的一个重要区别是：博客系统关心的是最终页面展示，而文章管理系统关心的是内容资产本身——文章的来源、版本、状态、关联素材、发布渠道记录。

所以很多人最终发现：与其去改一个CMS的各种插件和数据结构，不如自己写一套简单够用的管理系统。

2.2 主流技术方案对比

我见过、也实践过几套不同的搭建路径，这里直接梳理一个对比表，方便你根据自己的基础做选型。

对我个人来说，个人项目最舒心的组合是Node.js（或Python Flask）+ SQLite。原因有三个：

• SQLite是一个文件型数据库，不需要单独安装数据库服务，备份就是把文件拷走，这对个人项目非常重要。
• 单体应用部署简单，一个进程搞定，不需要Nginx转发多个服务，不需要容器编排。
• 数据量在几万篇文章以内，SQLite的性能完全够用，不要被“SQLite不适合生产环境”这种话吓到，它不适合的是高并发写入场景，而文章管理这种低频写入的场景，它稳得很。

2.3 核心功能模块设计

不管用什么技术栈，一套文章管理系统的核心模块大致是这些：

1. 文章模型：标题、作者、封面图、摘要、正文内容（Markdown或富文本）、标签、分类、状态（草稿/待审核/已发布/已下线）、发布时间、更新时间。
2. 内容入库：支持手动录入、Markdown批量导入、公众号图文消息复制粘贴导入。
3. 检索筛选：按标题模糊搜索、按标签/分类过滤、按日期范围筛选。
4. 数据统计：文章总数、各状态数量、每月发布量、标签分布、分类分布。
5. 内容导出：导出为Markdown、HTML、PDF，方便迁移到公众号编辑器或其他平台。

你可能注意到了，我没有提“评论”“用户系统”“权限管理”。个人项目，如果用不上，就不要在一开始设计进去，这是YAGNI原则——除非确定需要，否则不做。

3. 实操过程与核心环节实现

3.1 快速搭建一个基础项目

我从一个具体的实操项目切入，这套方案用Node.js + Express + SQLite，前端用轻量的服务端模板渲染，比如EJS，不搞前后端分离。为什么要用服务端渲染？因为这套系统是你自己或小团队内部用的，页面不需要承担复杂的交互，服务端渲染可以直接用模板输出数据，代码量少、部署简单、调试直观。

项目结构大概是这样的：

weixin105/ ├── app.js # 入口文件 ├── package.json ├── db/ │ └── database.js # SQLite初始化 ├── routes/ │ ├── articles.js # 文章相关路由 │ └── index.js # 首页路由 ├── views/ │ ├── layout.ejs # 布局模板 │ ├── index.ejs # 列表页 │ ├── edit.ejs # 编辑页 │ └── detail.ejs # 详情页 └── public/ └── css/style.css # 样式文件

入口文件的骨架是这样，比较干净：

const express = require('express'); const path = require('path'); const sqlite3 = require('sqlite3').verbose(); const app = express(); const PORT = process.env.PORT || 3000; // 中间件 app.use(express.urlencoded({ extended: true })); app.use(express.json()); app.use(express.static(path.join(__dirname, 'public'))); // 设置模板引擎 app.set('view engine', 'ejs'); app.set('views', path.join(__dirname, 'views')); // 路由 app.use('/', require('./routes/index')); app.use('/articles', require('./routes/articles')); // 启动服务 app.listen(PORT, () => { console.log(`文章管理系统已启动: http://localhost:${PORT}`); });

3.2 数据库表结构设计

数据库是这套系统的地基。我在设计文章表的时候踩过一个坑，就是一上来就想把“作者”“栏目”“来源平台”都拆成单独的表，觉得这样才规范。结果写代码的时候发现，个人项目根本用不上那么细的关联查询，反而把自己绕晕了。

所以后来我采用了“单表 + 简单字段”的设计：

CREATE TABLE IF NOT EXISTS articles ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, author TEXT DEFAULT '默认作者', summary TEXT DEFAULT '', content TEXT DEFAULT '', status TEXT DEFAULT '草稿', tags TEXT DEFAULT '', category TEXT DEFAULT '', source_url TEXT DEFAULT '', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP, published_at DATETIME );

几个字段的设计意图说明一下：

• tags用逗号分隔的字符串存储，而不是单独建关联表。因为文章系统对标签的查询场景通常是“筛选”，而不是复杂的多对多关系维护，这样设计代码最简单。
• status用文本字符串，而不是数字枚举。虽然数字更规范，但文本在维护时一眼就能看懂，调试时不用查映射表。
• source_url保留一个字段，记录文章最初发布的链接（比如公众号链接），方便溯源。

3.3 文章导入流程的关键

很多人在自己搭系统的时候，卡得最久的往往不是增删改查，而是“怎么把已经写好的内容弄进去”。公众号后台复制出来的图文，默认是富文本格式，带大量内联样式，直接存进数据库里，后期如果要导出成Markdown，或者展示在网页上，会出现样式错乱。

我后来在导入环节做了几个处理：

• 支持Markdown源文件批量导入，比如你本地有一批.md文件，可以通过一个上传页面一次性导入。
• 支持纯文本粘贴导入，从公众号后台复制的内容先经过一个“清洗函数”，去掉多余的空格、空行和特殊字符。
• 支持HTML源码粘贴，保留基本的段落结构，但不保留内联样式。

实现一个简单的Markdown导入函数，是这样：

const fs = require('fs'); const path = require('path'); const { parseMarkdownMeta } = require('../utils/parser'); function importMarkdownFiles(filePaths) { const results = []; for (const filePath of filePaths) { const raw = fs.readFileSync(filePath, 'utf8'); const meta = parseMarkdownMeta(raw); // 解析标题、标签、日期等元信息 results.push({ title: meta.title || path.basename(filePath, '.md'), content: meta.content, tags: meta.tags || '', category: meta.category || '', }); } return results; }

parseMarkdownMeta这个函数的作用，是把Markdown文件头部的YAML front matter（即---包裹的元数据区块）解析出来。如果你本地文件都有标准的文章头，导入效率会高很多。

3.4 检索与筛选的实现思路

文章管理系统“好用不好用”，检索能力是关键。我给这套系统做了三个维度的筛选：关键词、状态、分类。

关键SQL查询大概是这样的：

SELECT * FROM articles WHERE 1=1 AND (title LIKE ? OR tags LIKE ? OR category LIKE ?) AND status = ? ORDER BY updated_at DESC LIMIT ? OFFSET ?;

动态拼接查询条件时，要注意SQL注入问题。虽然SQLite的参数化查询习惯已经普及，但如果是自己写着玩，很容易图省事直接拼字符串。个人项目也是项目，该有的安全意识要有。

分页这里我用了LIMIT和OFFSET，简单直接。文章量在几千篇以内，性能完全不用担心。如果以后文章量大了，再考虑用游标分页。

3.5 样式与界面：够用就行

我不建议在个人项目的界面美化上花太多时间，但有几个地方值得注意：

• 列表页要一眼能看到标题、状态、更新时间这三维信息，再加一个“操作”列。
• 编辑页的正文编辑建议用Textarea + Markdown预览，没必要引入复杂的富文本编辑器。富文本编辑器带来的粘贴格式污染、大体积JS文件、版本兼容问题，在个人项目里都是负担。
• 搜索框要放在显眼位置，因为日常用得最多的一定是“找文章”，而不是“写文章”。

我的界面模板里，列表页的关键逻辑是这样的：

<table class="table"> <thead> <tr> <th>标题</th> <th>分类</th> <th>标签</th> <th>状态</th> <th>更新时间</th> <th>操作</th> </tr> </thead> <tbody> <% articles.forEach(function(article) { %> <tr> <td><a href="/articles/<%= article.id %>"><%= article.title %></a></td> <td><%= article.category %></td> <td><%= article.tags %></td> <td><%= article.status %></td> <td><%= article.updated_at %></td> <td> <a href="/articles/<%= article.id %>/edit">编辑</a> <a href="/articles/<%= article.id %>/delete" onclick="return confirm('确认删除？')">删除</a> </td> </tr> <% }) %> </tbody> </table>

4. 常见问题与排查技巧实录

4.1 时间字段差8小时的时区问题

个人项目里最容易忽略的坑，时区问题绝对排前三。SQLite的CURRENT_TIMESTAMP返回的是UTC时间，如果你直接用这个字段展示在页面上，会发现“更新时间”比北京时间慢8小时。

我当时没仔细想，直接把这个坑带到了测试环境，结果所有文章的时间都是错的。解决的办法有两种：

• 在存入数据时，直接使用本地时间字符串。
• 在查询时用datetime(updated_at, 'localtime')转换。

个人项目我推荐前者，代码改动最小：

INSERT INTO articles (title, content, status, created_at, updated_at) VALUES (?, ?, ?, datetime('now', 'localtime'), datetime('now', 'localtime'));

4.2 搜索时SQL模糊匹配的坑

用LIKE '%关键词%'做模糊搜索，如果输入的搜索词里本身带有%或_符号，结果会出问题。这两个符号在SQL的LIKE语法里是通配符，%匹配任意多个字符，_匹配单个字符。

如果用户搜了个“100%纯棉”这种词，就会匹配到一堆不该出现的内容。解决办法是转义：

SELECT * FROM articles WHERE title LIKE ? ESCAPE '\';

对应的参数值需要先替换：

const escaped = keyword.replace(/[\\%_]/g, (match) => '\\' + match);

这个细节看起来小，但等你把系统开放给其他同事用，就会遇到有人拿特殊字符搜索导致结果异常的情况。

4.3 富文本粘贴带来的“脏内容”

从公众号后台直接复制文章内容粘贴到系统里，正文会带着大量style内联样式、<section>嵌套标签，甚至还有JS代码片段。如果直接入库，后期如果要转成Markdown，或者展示到其他平台，会非常痛苦。

我的处理思路是三步：

1. 粘贴时用document.execCommand('paste')拦截，或者手动触发一个“清洗”按钮。
2. 清洗函数里用DOMParser解析HTML，只保留p、h2、h3、blockquote、ul、ol、li、strong、em、a、img这些标签。
3. 转存时统一转成Markdown格式。

清洗HTML的简易实现示例：

function cleanHtml(html) { const doc = new DOMParser().parseFromString(html, 'text/html'); const allowedTags = ['P', 'H2', 'H3', 'BLOCKQUOTE', 'UL', 'OL', 'LI', 'STRONG', 'EM', 'A', 'IMG']; const allElements = doc.body.querySelectorAll('*'); allElements.forEach((el) => { if (!allowedTags.includes(el.tagName)) { el.replaceWith(...el.childNodes); } }); return doc.body.innerHTML; }

实际使用中，这段代码省了我不止一次手工清理的功夫。

4.4 数据备份与迁移

SQLite的备份简单得让人怀疑：“就这么简单？”是的，直接把数据库文件复制一份就行。我建议在后端加一个管理接口，一键下载当前的数据库文件。这样即使系统部署在服务器上，备份和恢复都很快。

接口实现：

app.get('/admin/backup', (req, res) => { res.download(path.join(__dirname, 'db', 'database.sqlite'), 'backup.sqlite'); });

恢复数据就更简单了——停止服务、替换数据库文件、重新启动。整个过程一分钟以内。

4.5 部署时忘记设置环境变量

很多人本地跑通了，部署到服务器上却报端口冲突或者数据库路径找不到。原因基本都在环境变量和路径处理上。

推荐用.env文件统一管理配置，Node.js可以直接用dotenv库加载：

require('dotenv').config(); const PORT = process.env.PORT || 3000; const DB_PATH = process.env.DB_PATH || path.join(__dirname, 'db', 'database.sqlite');

部署到服务器后，只需要在项目目录新建.env文件，写入对应的端口和数据库路径即可，避免把路径写死在代码里。

5. 从单机版到团队协作的扩展

5.1 何时需要考虑加“用户系统”

个人系统用着用着，难免会萌生“要不要让同事/朋友一起来用”的想法。如果系统部署在内网，或者你愿意做端口映射，那给每个成员一个账号，记录每篇文章的维护人，是自然的演进方向。

加用户系统之前，先想清楚这几个问题：

• 谁会用到这个系统？只有你，还是团队？
• 要不要区分“只读”和“可编辑”权限？
• 要不要保留“每篇文章由谁创建、谁修改”的审计记录？

如果答案都是肯定的，那就引入简单的用户表和登录功能。这时候我用的是Session + SQLite存储用户，不用JWT，因为内部系统没有跨域、免登录等需求，Session方案实现简单且够用。

5.2 引入发布渠道管理

文章系统的下一层需求，往往是从“管理内容”走向“管理发布”。如果你同时运营公众号、知乎、掘金、博客多个平台，每条文章发到哪些平台、每个平台最终状态如何、各个平台链接，都是很有价值的信息。

升级方案是在文章表中增加一个publish_logs表：

CREATE TABLE publish_logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, article_id INTEGER NOT NULL, platform TEXT NOT NULL, url TEXT DEFAULT '', publish_status TEXT DEFAULT '未发布', published_at DATETIME, FOREIGN KEY (article_id) REFERENCES articles(id) );

这样，一篇文章有哪些发布记录、每个平台是否成功，一目了然。

5.3 文本分析：从“管理”到“洞察”

等文章积累到一定数量，很多人会想：能不能分析一下我到底写过什么主题、哪些内容阅读量高、有没有我忽略的选题方向？

这时候可以用简单的Python脚本，把SQLite中的文章导出成表格数据，然后用jieba做中文分词、wordcloud生成词云、collections.Counter统计标签分布。技术含量不高，但非常有价值。

一个简单的标签统计脚本：

import sqlite3 import jieba from collections import Counter conn = sqlite3.connect('database.sqlite') rows = conn.execute("SELECT title, content FROM articles").fetchall() word_count = Counter() for title, content in rows: words = jieba.cut(title + ' ' + content) word_count.update(w for w in words if len(w.strip()) > 1) for word, count in word_count.most_common(30): print(word, count)

这个脚本跑出来的结果，往往能给你一种“原来我一直在写这个方向”的恍然大悟感。

6. 实践心得与避坑清单

6.1 “能跑就行”与“规范化”的平衡

做个人项目最怕的就是两个极端：一个极端是过度设计，一上来就架构分层、消息队列、分布式；另一个极端是完全没有规范，所有代码写在一个3000行的文件里，之后改一行都胆战心惊。

我的经验是：核心模块用规范化的方式写，非核心的、纯辅助的功能，怎么快怎么来。文章增删改查、导入导出、搜索筛选，这些是核心，用清晰的函数拆解；页面样式、小工具、管理操作，这些可以糙快猛，不影响主线逻辑。

6.2 给“写文章”留一条最快的路

文章管理系统再方便，如果你的主要精力在“写”而不是“管”，那么系统能不能让你快速进入写作状态，非常重要。

我最后给系统加了一个功能：一键新建文章的入口，不跳转编辑页，直接默认填充“标题 + 草稿状态”，然后焦点落在正文编辑区。就这么一个小细节，极大降低了“建一篇文章”的心理门槛。

6.3 项目命名与URL设计的实用建议

关于“weixin105”这个项目代号，我多说一句。内部项目代号建议语义化一点，不要用纯数字编号，这样别人看到/weixin105/不知道是什么，你三个月后再看到也要回忆半天。

好的命名方式是“用途 + 环境标识”，比如：

wechat-article-manager-dev wechat-article-manager-prod

命名清晰，路径清晰，部署时不容易出错，后期接手的人也更容易理解。

6.4 我踩过的几个坑汇总

最后把几个重要经验集中列一下，方便你对照检查自己的实现。

6.5 后续还能怎么扩展

这套系统的后续扩展空间其实很大：

• 接入微信公众平台的开放接口，把公众号后台的文章列表自动拉取进来。
• 增加文章阅读统计，通过分析公众号后台的阅读数据，管理端直接展示。
• 增加定时发布提醒，根据你设定的发布计划，提醒你到点发布。
• 生成月度内容报告，汇总发布数量、分类占比、标签热词。

我个人最看好的扩展方向，是“自动拉取公众号历史文章”。这个功能一旦做好，这套文章管理系统就不再只是“自己录入内容的工具”，而是“公众号内容资产管理平台”，价值会完全不一样。

写在最后的个人体会

做“weixin105文章管理系统”这类项目，最大的收获并不是代码本身，而是搞清楚了一个道理：工具的价值不在于功能列表有多长，而在于它能不能融入你的日常操作流程。一套系统做得再好，如果你每天不想打开它，那它就是失败的；做得糙一点，但每次写文、找文、整理文档都顺手，那就是成功的。

我在实际使用中，刻意把“新建文章”的路径缩短到两次点击以内，把“搜索”放到列表页最显眼的位置，把“发布状态”做成一眼能看懂的颜色条，这些都是在给自己减少摩擦。管理系统的本质是降低内容管理的认知负担，而不是增加负担。

如果你也想动手搭一套，希望这篇分享能帮你少走几步弯路。不用一开始就追求大而全，先把你最痛的那个场景解决掉，跑起来以后，再慢慢加功能，这条路最实际。