米思齐这个名字最早只是工作室里一门创客教育课程的名字后来课程体系越做越厚讲义、活动照片、老师介绍、课程报名入口全都散在各处团队里每个人都问过官网到底什么时候能上。于是我接手做了这件事前后折腾了一个多月最终落地方案就是标题里这行字米思齐 WordPress。如果你正在纠结用 WordPress 建站到底靠不靠谱或者已经决定用但不知道从哪里下手这篇文章应该能帮你省掉不少弯路。我按照实际推进的顺序把选型理由、本地环境搭建、主题插件选型、团队写作流程改造、上线部署细节、以及后续性能维护这几个阶段全部拆开来讲中间会穿插一些我真实踩过的坑和最终采用的解决办法。整个站点不是多复杂的项目但该踩的坑基本都踩了一遍该沉淀的经验也都在这里了。1. 为什么最终选了 WordPress团队和维护成本是第一位的1.1 我们最初看的几个方案米思齐不是要做电商平台也不是要做日活百万的资讯站核心需求就三个运营和课程老师能自己发布课程信息、公告、活动记录课程详情页要有固定的信息结构比如适用年龄、课时、费用、老师介绍数据要掌握在自己手里不能平台一改规则就跟着被动。按这个需求去筛方案最先排除的反而是很多人最看好的技术方案。静态站点生成器是我最初很想用的方案。Hugo、Astro 这套东西在我自己手里完全不是问题本地写 Markdown、构建、push 到服务器一条命令搞定。但问题出在内容团队身上。课程老师是不应该去学 Git 工作流的他们想要的只是打开后台点新建文章把内容贴进去发布这么简单。如果为了追求极致的性能让全团队付出额外的协作成本这个账怎么算都不划算。SaaS 建站平台也看过几个页面拖拽确实方便但一涉及到自定义课程报名表单、会员列表、自定义文章类型这些需求免费版基本都做不到付费版按年订阅下来费用并不低。更关键的是哪天我们想换平台数据能不能完整导出是个很大的未知数。独立开发一套简单 CMS 的方案我也认真考虑过因为团队里就我一个全职开发用熟悉的技术栈写一套内容管理后台短期内确实爽。可一旦上线后续任何新需求都要从代码层面改一个人长期维护一套私有系统会从一个建站项目变成无底洞项目。1.2 WordPress 的生态才是真正的竞争优势最后定下来用 WordPress不是因为它在技术上有多领先而是它的生态让维护成本变得极其可控。WordPress 到今天已经积累了非常庞大的主题和插件市场插件目录本身就像是一个应用中心遇到一个问题先搜一下大概率能找到已经被大量用户用过、持续维护的现成方案。比如我们需要的课程自定义字段、报名表单、SEO、缓存、备份每一个领域都有成熟插件装上去配置一下就能用并不需要从头写逻辑。这正好对冲了团队小、技术资源有限的短板。我可以把精力放在真正需要定制的地方而不是重复造一顿轮子。对比下来我们的选型结论是这样的方案内容团队上手成本功能扩展成本数据可控性长期维护成本静态站点生成器高高高低SaaS 建站平台低中等低中高自研 CMS高很高高非常高WordPress低低高低当时团队里也有人质疑说 WordPress 太老、太慢、不安全。这几个担忧我在后面的实操章节里都会聊到。先说结论WordPress 的慢绝大多数是缓存没做好、插件装太多、主题质量太差导致的和安全问题一样基本都是运维和管理的问题不是系统本身的问题。2. 先在一台小主机上跑通本地环境再碰线上服务器2.1 一台被叫成小面皮的旧主机正式买服务器之前我在工作室一台旧的小主机上把整套环境搭了一遍。这台机器其实很普通朋友淘汰下来的准系统小主机机身扁平方正被大家开玩笑说像一碗切好的小面皮于是后来我们内部都叫它小面皮。配置也不豪华四核低功耗 CPU、4GB 内存、120GB SSD。跑一个开发环境完全够用如果只是做内容站点这个配置甚至能支撑一个小型生产环境。很多人建站犯的毛病是一上来就买服务器、装宝塔、传主题然后在线上边搜教程边改。这样做的最大问题是一旦主题或插件报错线上网站直接变白屏连个回滚的地方都没有。我在小面皮上先跑通一切核心目的就是所有危险操作先在本地试试好了再上线。本地环境我在 Ubuntu 上搭具体系统版本是 Ubuntu 22.04 LTS。为什么用 Linux 而不是直接在 Windows 里装一个集成环境因为线上服务器也是 Linux本地和生产环境保持一致能省掉大量本地没问题上线就炸的玄学问题。2.2 小面皮上的部署清单从 Nginx 到 WP-CLI在小面皮上部署的时候我顺手把步骤记录了下来基本是这样一套流程。第一步安装基础软件。我用 Nginx 做 Web 服务器、MariaDB 做数据库、PHP 8.1-FPM 跑动态请求。在 Ubuntu 22.04 上直接用 apt 装就能拿到这些版本。sudo apt update sudo apt install -y nginx mariadb-server php8.1-fpm php8.1-mysql \ php8.1-xml php8.1-mbstring php8.1-curl php8.1-gd unzip第二步安装 WP-CLI。这个工具后面会反复用到强烈建议所有 WordPress 使用者都装一个它能让你完全脱离网页后台去操作站点迁移、批量改、调试都靠它。curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar chmod x wp-cli.phar sudo mv wp-cli.phar /usr/local/bin/wp wp --info第三步创建数据库和用户。注意选择 utf8mb4 字符集不然中文内容很容易在迁移中出现乱码。sudo mariadbCREATE DATABASE mixiqi_wp DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER mixiqilocalhost IDENTIFIED BY 换成你自己的强密码; GRANT ALL PRIVILEGES ON mixiqi_wp.* TO mixiqilocalhost; FLUSH PRIVILEGES; EXIT;第四步用 WP-CLI 下载并安装 WordPress。我选择了中文语言包后面切换也方便。cd /var/www sudo mkdir mixiqi sudo chown $USER:$USER mixiqi cd mixiqi wp core download --localezh_CN wp config create --dbnamemixiqi_wp --dbusermixiqi --dbpass数据库密码 \ --dbhostlocalhost --localezh_CN wp core install --urlhttp://mixiqi.local --title米思齐 \ --admin_useradmin --admin_password管理员密码 \ --admin_emailyouexample.com第五步给小面皮配上 Nginx 站点。我在/etc/hosts里加了127.0.0.1 mixiqi.local然后在 Nginx 配置里写了最基础的 server 块server { listen 80; server_name mixiqi.local; root /var/www/mixiqi; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } }这一套跑起来之后访问mixiqi.local就能看到 WordPress 安装完成了。2.3 本地这套环境到底用来干什么本地环境搭好之后它承担了三件事第一主题开发。所有子主题的 PHP 文件修改、样式调整我都在本地改完并测试通过再同步到线上。这样就算改坏了也不影响任何线上访客。第二插件验证。新插件先装到小面皮上看它有没有性能问题和已有插件有没有冲突配置项是否正常。验证没问题之后再在线上装同款。这一步能避免很多线上白屏事故。第三内容迁移演练。我们后续从老站点迁移内容、从 Markdown 导入文章所有脚本都在本地先跑一遍确认无误再对线上执行。顺便说一个细节在本地开发模式下我会直接把页面缓存关掉只保留 PHP 的 opcache。原因是缓存会把真实的页面渲染问题掩盖住本地开发时需要看到的是没缓存时到底慢不慢、报不报错而不是缓存兜底之后的正不正常。3. 主题选型和应用中心式改造3.1 用父主题加子主题的方式做定制WordPress 建站选主题是一个很容易让人上头又容易翻车的环节。市面上主题成千上万免费的有付费的也有漂亮的更多。但我们的立场从一开始就很明确不会花钱买盗版也不选那些什么都想做的全家桶主题。我最终选了 GeneratePress 作为父主题主要原因是它的代码规范、体积小、默认渲染速度很快而且无障碍支持做得不错。这是很多好看但臃肿的商业主题完全比不了的地方。选好父主题之后我在它上面建立了一个自己的子主题命名为mixiqi-child。为什么要做子主题因为父主题会更新如果每次都直接改父主题文件下次更新一覆盖所有自定义代码就全没了。子主题是 WordPress 官方推荐的做法它继承父主题的全部样式和功能同时允许你在子主题里覆盖和扩展自己需要的东西。子主题其实只需要两个文件style.css和functions.php。style.css的开头注释很重要它被 WordPress 用来识别子主题信息/* Theme Name: Mixiqi Child Template: generatepress */这里面的Template字段必须和父主题的目录名一致少了这一行子主题根本不会被识别。functions.php里先注册父主题样式和一个子主题自己的样式add_action( wp_enqueue_scripts, function() { wp_enqueue_style( parent-style, get_template_directory_uri() . /style.css ); wp_enqueue_style( child-style, get_stylesheet_uri(), array( parent-style ) ); } );这样一个干净的子主题就完成了后续所有自定义代码都通过子主题的functions.php或额外的模板文件来加父主题随便更新都不用怕。3.2 按应用中心思路选插件主题定下来之后接下来是插件。WordPress 的插件生态像应用中心好处是海量选择坏处也是海量选择——很多人一进后台就忍不住装一堆最后页面加载出一大堆用不上的样式表和脚本。我给米思齐站点选插件时定了一个原则一个需求只留一个插件且优先选官方目录里更新活跃、用户量大、评价好的。最后留下的插件清单大概是这样的插件解决的需求替代方案ACF课程自定义字段核心自带自定义字段太基础Fluent Forms课程报名表单Contact Form 7 太老套Rank Math标题描述和 SEO 基础Yoast 偏重配置项太多Redis Object Cache对象缓存必须配合 Redis 服务端Code Snippets管理零散的 PHP 代码片段避免全塞进 functions.phpACF 是我们整个站点最依赖的插件。课程详情页里适用年龄、课时安排、老师姓名、封面图这些都靠 ACF 的字段组管理起来。没有它这些结构化信息要么硬编码进页面模板要么塞进文章正文里后面的维护会非常痛苦。Fluent Forms 是我对比之后选的表单插件主要用它做一个课程报名的表单提交之后可以自动发邮件通知运营同事。它的 UI 清晰数据存在自己的表里不需要额外接第三方服务。Rank Math 负责每个页面和文章的标题、描述、结构化数据输出。WordPress 自带的基础 SEO 能力其实很弱这类插件还是需要的。3.3 砍掉的那些插件以及我为什么砍和很多人一样我也经历过啥都想装的阶段。后来都砍了。页面构建器类插件我直接砍掉了。Elementor 这种工具拖拽起来确实爽但它会把页面变成一堆内部短代码和 HTML 注释后期维护特别难受而且加载的资源很重对页面性能影响非常大。WordPress 现在自带的古腾堡编辑器加上 ACF 已经能覆盖我们绝大部分的建站需求完全不需要再上页面构建器。安全类全家桶也砍了。Wordfence 这类插件功能确实强大但它的后台扫描和防火墙规则会占用不少服务器资源而且很多规则对一个内容型小站来说是用不上的。我的方案是服务器层面做好 SSH 登录限制、文件权限收紧、自动更新插件再配合备份效果并不会差。后文安全部分会详细说。还有一些多合一 SEO 插件功能过于庞大我们只需要最核心的标题、描述、站点地图Rank Math 免费版已经足够没必要为了一堆用不上的功能去牺牲后台流畅度。3.4 自己写出来的课程列表块主题和插件就位后真正需要写代码的部分其实是首页的课程列表。这个列表要按课程分类展示每门课显示封面、标题、一句话简介和报名链接。思路是给 ACF 加一个是否在首页展示的开关字段然后用WP_Query去查课程这个自定义文章类型输出成卡片结构。代码放到子主题的functions.php里用短代码的形式挂在首页这样页面编辑人员可以随时决定把列表放在哪个位置。add_shortcode( mixiqi_courses, function() { $query new WP_Query( array( post_type course, posts_per_page 6, orderby date, order DESC, meta_query array( array( key featured_on_home, value 1, ), ), ) ); if ( ! $query-have_posts() ) { return p暂无课程/p; } ob_start(); echo div classmixiqi-course-grid; while ( $query-have_posts() ) { $query-the_post(); $cover get_field( cover_image ); echo div classmixiqi-course-card; if ( $cover ) { echo img src . esc_url( $cover[url] ) . alt . esc_attr( get_the_title() ) . ; } echo h3 . get_the_title() . /h3; echo p . esc_html( get_field( short_intro ) ) . /p; echo a href . get_permalink() . 查看详情/a; echo /div; } echo /div; wp_reset_postdata(); return ob_get_clean(); } );这段代码就是标准的 WordPress 开发姿势查询、循环、输出。没有任何神秘技巧但足够稳定。用短代码而不是直接改首页模板是因为这样页面编辑人员可以在古腾堡编辑器里自由拖拽位置不需要每次请开发者改代码。4. 让写作团队继续用 MarkdownWordPress 负责渲染4.1 为什么不能强迫所有人都学古腾堡古腾堡编辑器其实已经很强大了块结构非常适合做富文本内容。但问题在于米思齐团队里的课程老师之前已经有了一套很成熟的写作习惯他们用 Markdown 写讲义写到一半的文件放在共享目录里标注好了交付状态。如果迁到 WordPress 之后要求所有人都在后台编辑器里从头写相当于强行换掉大家已经跑顺的工作流阻力会非常大。我们的目标不是让所有人改变习惯而是让 WordPress 去兼容团队已有的写作习惯。这也是标题里米思齐引用 Markdown这个需求的由来。讨论下来团队写作流程保持这样课程老师继续在本地用 Markdown 写正文统一放到一个约定好的目录我提供一个发布脚本把 Markdown 文件转成 WordPress 能识别的格式再通过 WP-CLI 写进站点。老师在浏览器里看到的最终效果和后台排版一致仍然可以修改已发布的内容。4.2 从 Markdown 到 Gutenberg 块的转换链路Markdown 转 Gutenberg网上有很多现成方案比如 WP Githuber MD 插件可以在后台直接用 Markdown 编辑器。但我不太想在一个内容型小站里再引一个额外的大插件而且我们更希望 Markdown 文件本身是团队的资产WordPress 只是一个发布管道。所以我选了一条更可控的路本地用 Markdown 转换工具生成 HTML再把 HTML 包装成 Gutenberg 能识别的 HTML 块最后通过 WP-CLI 导入。具体链路大概是这样的Markdown 文件 - 解析 YAML 头部标题/分类/标签 - 转换正文为 HTML - 包装成 Gutenberg HTML 块 - wp-cli 导入 - 发布这里最省事的包装方式是先用 Gutenberg 的 HTML 自定义块把转换好的 HTML 包起来。HTML 块的好处是所见即所得后续想升级成真正的段落块、标题块、图片块也可以再单独解析不影响线上显示。一个简化的转换脚本用 Python 写大概长这样import markdown import frontmatter import subprocess import tempfile # 读取 Markdown 文件 post frontmatter.load(course-intro.md) # 正文转 HTML html_body markdown.markdown( post.content, extensions[fenced_code, tables, codehilite] ) # 包成 Gutenberg HTML 块 gutenberg_block f!-- wp:html --{html_body}!-- /wp:html -- with tempfile.NamedTemporaryFile( modew, suffix.html, deleteFalse, encodingutf-8 ) as f: f.write(gutenberg_block) temp_path f.name # 导入 WordPress subprocess.run([ wp, post, create, --post_typecourse, --post_statusdraft, f--post_title{post[title]}, f--post_content-file{temp_path}, ])脚本读完 Markdown 之后会生成一个.html临时文件里面是包好的 Gutenberg 块结构然后通过--post_content-file参数传给 WP-CLI。这样就算文章很长也不会被 shell 参数长度限制卡住中文也不会因为转义出问题。4.3 实际转换中踩过的三个细节坑这个流程跑通之后我还是遇到了一些问题这几个坑如果你也要做 Markdown 导入大概率会碰上。第一个坑是图片路径。Markdown 里的图片引用通常是相对路径比如。直接导入 WordPress 后图片 URL 是指向本地的线上访客根本看不到。解决办法是先用wp media import把图片传到媒体库拿到线上 URL再把 Markdown 里的相对路径替换掉最后才执行转换和发布。第二个坑是代码块。Markdown 的三反引号代码围栏转换器会生成precode结构但 Gutenberg 的代码块需要额外的注释标记!-- wp:code --。如果直接塞进 HTML 块里代码样式和其他块不一致。我后来的处理方法是在转换前先把代码块内容提取出来做占位符等转换完成后再替换回带wp:code注释的块结构。这样代码高亮和样式才能和正常 Gutenberg 代码块一致。第三个坑是脚注。Markdown 里用脚注写注释很方便但转换之后Gutenberg 并没有原生的脚注块输出的 HTML 会以很奇怪的样式挂在文章末尾。团队后来约定正式对外发布的文章一律不用脚注需要补充说明的文字直接写在正文里。上面这套流程跑顺之后课程老师发课程的体验是本地写完 Markdown扔进约定目录说一声这篇可以发布了我执行一下脚本课程就出现在网站上了整个过程不超过两分钟。5. 建站流程的完整顺序域名、服务器、迁移、HTTPS、备份5.1 域名与部署商家的选择本地环境万事俱备之后第二步才是真正碰生产环境。域名这件事没什么好纠结的我们把mixiqi.com注册了下来。注册时我特别看了一眼是否包含隐私保护以及自动续费是否开启不然域名到期忘了续费整个网站流量会全部中断。服务器和部署商家的选择很多人问过我开源部署到底有什么讲究。其实这里说的核心是商家的环境允不允许你自己安装和修改程序文件、能不能通过 SSH 登录、数据库是不是自己可控。有些所谓WordPress 托管主机虽然也是一键安装但连 SSH 都不给那本质上就是个高度受限的运行环境算不上开源部署。我当时的筛选条件很简单支持 PHP 8.1 以上Web 服务器用 Nginx 或兼容 Nginx 规则的方案提供 SSH 登录权限数据库可以用命令行管理能做定时备份机房位置主要考虑国内用户访问速度。这里不具体点名厂商但提醒一句不要一上来就买最高配内容型小站 2 核 4G 起步已经很够用后续流量大了再垂直扩容也不会太麻烦。5.2 本地到线上的迁移顺序这一步我刚开始差点翻车所以把顺序写清楚。本地站点已经调试好了现在要把整套数据推到线上。我的迁移顺序是这样的第一步在本地导出数据库。WP-CLI 有现成的命令wp db export mixiqi-local.sql第二步打包上传目录。文章的图片都存在wp-content/uploads下面必须完整打包过去tar -czf uploads.tar.gz -C wp-content/uploads .第三步在线上服务器创建数据库、导入数据。数据库名、用户名可以先在服务器上建好然后执行wp db import mixiqi-local.sql第四步也是最关键的一步替换站点 URL。本地用的是http://mixiqi.local线上是https://mixiqi.com。如果不替换点开任何链接都会跳回本地地址。wp search-replace http://mixiqi.local https://mixiqi.com \ --skip-columnsuser_pass --precise --recurse-objects \ --all-tables-with-prefix这里用--skip-columnsuser_pass是为了避免误改用户表里的密码哈希一旦改了密码哈希所有人都会登录失败。第五步把线上wp-content/uploads里的内容替换成刚才打包的文件cd /var/www/mixiqi tar -xzf uploads.tar.gz -C wp-content/uploads第六步清缓存。如果之前配置了任何缓存替换完 URL 之后一定要清一遍否则页面里还残留着旧地址的引用。5.3 Nginx 伪静态和 HTTPS 配置迁移完成后站点虽然能访问但固定链接如果设置成文章名这种形式必须让 Nginx 支持伪静态否则所有内页都会 404。在 WordPress 的 Nginx 配置里最核心的是这一段location / { try_files $uri $uri/ /index.php?$args; }意思是如果请求的路径不是真实文件就交给index.php去处理。WordPress 的固定链接机制就是依赖这一条规则运行的。之后是 HTTPS。我用 certbot 来申请和自动续期证书一条命令就能把证书和 Nginx 配置全部搞定。sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d mixiqi.com -d www.mixiqi.com装完之后把站点地址设置成https://mixiqi.com然后把 HTTP 请求强制跳转到 HTTPScertbot 默认会帮你配置好这个跳转。有一点要注意如果站点启用了 CDN 或者是反向代理SSL 证书的申请和续期方式可能会不同需要在申请前确认 DNS 是直接指向服务器而不是被 CDN 代理。5.4 备份策略数据库加站点目录双轨备份这件事太多人抱着以后再说的心态但真出事的时候往往已经晚了。我采用的策略是数据库和站点文件双轨备份。数据库备份用 WP-CLI 导出压缩后保留最近 7 天wp db export backup-$(date %F).sql gzip backup-$(date %F).sql站点文件备份不用全站拷贝只需要备份容易被改动的内容主题、插件和上传目录。核心程序文件后期可以通过重新安装恢复。tar -czf site-files-$(date %F).tar.gz \ wp-content/themes/mixiqi-child \ wp-content/plugins \ wp-content/uploads更重要的是要把备份文件同步到另一台机器或者对象的存储空间绝对不能留在同一台服务器上。不然服务器硬盘挂了备份也跟着一起没了。这个备份任务我用系统的 cron 定时跑不依赖 WordPress 内部的定时器。6. 上线之后的性能与维护WordPress 慢不慢取决于怎么养6.1 做对缓存一半问题就解决了很多人说 WordPress 慢其实是因为没有任何缓存机制。每次用户访问一个页面PHP 都要重新执行一遍数据库也都要查一遍当然快不到哪里去。我给米思齐站点做了两层缓存。第一层是 Nginx 的 FastCGI 缓存它在 Nginx 这一层直接缓存 PHP-FPM 返回的完整 HTML。游客访问时请求根本不会进到 PHP直接由 Nginx 把静态 HTML 返回给浏览器速度可以做到毫秒级响应。第二层是 Redis 对象缓存它缓存的是 PHP 对象比如数据库查询结果、永久链接结构、菜单数据。它能减少数据库的重复查询压力后台登录状态下依然有效所以配合页面缓存用很合适。安装 Redis 之后在 WordPress 里启用一个对象缓存插件并在wp-config.php里加一行配置关联到 Redis 服务即可。6.2 安全加固我只做了四件事关于 WordPress 安全外面说法很多动不动就是全家桶安全插件。我的做法相对简单但到目前为止没有发生过任何安全问题。第一件事关闭 XML-RPC。这个接口在旧版本里被大量用来做暴力破解和 DDoS 攻击现在的站点基本用不到。在 Nginx 配置里直接拒绝即可。第二件事服务器 SSH 登录关掉密码认证改用密钥登录。这是整个服务器安全的基础比任何安全插件都更有效。第三件事WordPress、主题、插件保持更新。这个看似简单但很多人忽略。米思齐的维护周期表里插件更新是每周一次主题更新和 WordPress 大版本更新要看兼容性先在本地小面皮上测试再上生产。第四件事定期检查和恢复备份。备份不能只做不看我每季度会在小面皮上做一次完整恢复演练确认备份文件真的能恢复出一个能访问的站点。没做过恢复演练的备份在心理上只能算数据双份不能算真正的备份。6.3 我的日常维护节奏上线这么久运行稳定没有出过严重事故。这并不完全是运气好更多是因为维护节奏很规律。频率要做的事每天自动备份数据库到远程存储每周更新插件、查看错误日志、检查磁盘空间每月检查 PHP 版本更新、查看访问日志里的扫描特征每季度完整恢复演练、检查 SSL 证书续期状态在运维上还有一个我亲测有用的习惯把 WordPress 自带的wp-cron关掉改成系统级的 cron 定时执行。WordPress 自带的定时任务依赖用户的访问来触发如果站点访客不多定时任务执行会非常不准确经常出现明明设置了定时发布结果过了半天才发出去的情况。在wp-config.php里加一行设置define( DISABLE_WP_CRON, true );然后到系统 crontab 里添加一条*/15 * * * * cd /var/www/mixiqi wp cron event run --due-now /dev/null 21这样定时任务完全由系统可靠地触发不再依赖访客流量。最后再说一个很多人忽略的小细节WordPress 后台的隐私设置里默认会生成一个隐私政策页面建议认真填一下内容不要直接删掉尤其是做课程报名、收集用户表单信息时这既是合规要求也是让用户放心提交信息的基础。米思齐这个站点到现在已经稳定运行大半年了课程老师继续按自己的习惯写 Markdown运营同学在后台直接编辑也完全没问题我作为唯一的开发者不需要频繁介入。WordPress 确实不是最时髦的方案但它让一个小团队用极低的维护成本把内容站稳下来了。如果你也在评估建站方案别被网上那些WordPress 过时了WordPress 慢的结论带偏先想清楚你的团队协作方式再决定用什么工具多半结论会和我不谋而合。