去年帮一个做餐饮的内容朋友看后台，他指着屏幕上一堆没配图的管理菜品直叹气。那套系统是系统外包公司五年前做的，后台只有标题和正文两个输入框，内容想加张图得先传到图床，管理再把链接复制回来。系统他问我能不能改改，内容我说这哪是管理改的问题，这是系统换的问题。这就是内容CMS最要命的地方——内容生产流程一旦被技术卡住，编辑的管理创造力就全耗在跟界面较劲上了。

CMS，系统内容管理系统，内容说白了就是管理一套让非技术人员能往网站里填东西的工具。但很多人把它想简单了，系统以为就是个富文本编辑器加数据库。我见过太多项目，选型时只看功能列表，上线后才发现编辑每天要花半小时处理格式错乱。Word里复制过来的文字带着隐藏样式，粘进编辑器就炸，前端页面跟着遭殃。这事儿怪谁？怪CMS没做好粘贴过滤。

真正好用的CMS，得在三个地方下功夫。第一是字段设计要灵活。新闻稿和产品页要填的东西能一样吗？产品页得有价格、规格、库存状态，新闻稿得有作者、来源、发布时间。如果系统只给一套通用字段，编辑就得把价格写在正文里，后面想做个比价功能都抓瞎。WordPress靠自定义字段和插件撑起了半壁江山，但插件装多了数据库臃肿得吓人，查询慢得像老牛拉车。

第二是模板和内容的分离要彻底。我见过一个政府项目，编辑改个标题颜色得找开发，因为颜色写死在模板文件里了。这种CMS等于没做。好的做法是把展示逻辑抽成组件，编辑在后台选“红色标题”样式，前端自动套class。Strapi和Contentful这类Headless CMS就是这么干的，内容通过API吐给前端，前端爱怎么渲染怎么渲染。但这对小团队不友好，多一层API就多一层运维成本。

第三是版本控制和预览。编辑改完文章，总得看看发出去什么样吧？有些CMS的预览就是个iframe套着前端页面，登录态都带不过去，图片全裂。更别提多人协作时的冲突——张三改了标题，李四改了正文，保存时后提交的覆盖先提交的，谁都不知道发生了什么。Git那套版本管理思路搬到CMS里，做起来不难，但很多商业CMS就是不做，因为用户“不需要”。真的不需要吗？你让法务审合同条款的时候改错一个字试试。

选CMS别光看官网Demo。下个Docker镜像本地跑跑，拿你们最复杂的内容类型建个模型，让编辑实际用半天。我见过编辑因为后台加载超过三秒就摔鼠标的，也见过因为不能批量替换关键词而加班到凌晨的。技术选型会上没人替他们说话，但系统难用，最后挨骂的还是技术团队。

还有个坑是数据迁移。换CMS时老内容怎么办？导出成XML再导入？字段对不上，图片路径全断，标签变成一堆乱码。我建议新项目直接上Headless架构，内容存Markdown加YAML front matter，哪天想换系统，文件拷走就行，不绑死在某个厂商的数据库里。虽然对编辑来说Markdown有点门槛，但培训两天总比被锁定五年强。

说到底，CMS不是给程序员用的，是给每天要发二十条内容的人用的。他们不关心底层是MySQL还是PostgreSQL，只关心上传图片会不会卡、保存按钮点下去有没有反应、改完标题能不能立刻看到效果。把这些细节做顺了，比堆一百个用不上的功能强得多。