星桥 API
今天整理星桥的公众号文章时，冒出了一个挺实在的问题：微信里发完，官网要不要也留一份？
要。但要是每发一篇，都得重新打包网站、上传一遍旧图片，再顺手改目录和搜索资料，这活儿干久了，文章没写几篇，自己先成搬运工了。
所以我们做了一次改造：文章单独更新，没变化的旧文件复用，网关主程序和前端不跟着重新部署。
截至 11 月 2 日，这次已把公众号的 10 篇长文章放进官网文章库。下面讲的是这次实际做了什么，也有还没省掉的步骤。
先别急着“全自动”，得知道搬的是哪一版
第一件麻烦事，居然不是上传速度，而是对稿。
公众号后台有长文章，也有同题贴图；本地还有改稿和草稿。看标题差不多就一股脑往官网倒，容易把草稿公开，或者把同一主题的两种形式各算一篇长文章。
我们这次先核对了正式链接、发表时间、正文和图片。官网原有 2 篇，补进 8 篇；另外 5 条同题贴图，没有再复制成 5 篇长文章。
这里保留了一道人工确认：用户看过并同意的稿件，确认已经在公众号发表后，才进入官网同步。
如果是人工在微信后台发表，下次检查时再核对补齐。目前没有“微信一发表，官网立刻自动抓取”的实时回调。这个区别得讲明白，不能拿一张流程图就给自己封个全自动。
流程图由星桥 API 生成，说明本次工作方式，不是后台运行截图。
把“发文章”和“发网站程序”拆开
我们这次没有给文章新建一套数据库后台。做法是把正文、图片和文章资料整理成独立内容文件，再生成文章页面。
每篇文章有自己的固定网址。新增文章时，文章列表、标题摘要、搜索引擎可读取的页面资料，以及 sitemap 一起更新。sitemap 可以理解为给搜索引擎看的网址清单。
这部分有变化，就更新这部分。API 网关主程序和网站前端，可以按自己的节奏发布，不需要为了加一篇文章也陪跑一趟。
打个比方，往图书馆加一本书，更新书架和目录就行。没必要把图书馆大楼重新盖一遍，工程队也挺忙的。
官网这边也不只留一个跳回微信的标题：正文和图片能直接阅读，图片保存在自有网站，文章同时保留公众号原文关联。这样网站本身就是可用的资料库。
11 月 2 日迁移核验时保存的官网实际页面，浏览器手机宽度截图；不等同于微信真机测试。星桥 API 由我们运营。
旧图片别跟着新文章来回跑
拆开发布以后，还有一件事值得省：每次都重传历史图片。
我们的处理方式，是给文件计算内容指纹。可以把它理解成按文件内容生成的标记，用来比较这次和上次有没有变化。
变了的文件才上传；没变的旧文件，在服务器复用。已生成且没有变化的文章页面，也可以用缓存结果。
本次补齐文章时，内容包共有 46 个文件，实际上传了其中 36 个，内容字节约 26 MB。这是这次补齐的记录，不是今后每篇文章的固定大小。
接着，用完全相同的内容再跑一次：10 篇文章页面全部命中渲染缓存，变化文件为 0，内容上传为 0 字节，线上内容版本没有切换。
注意，这不等于整次操作零耗时、零网络请求。版本清单还要读取，公共目录还要检查，本地也仍需核对文章资料和文件指纹。随着文章增多，这些步骤仍有成本；省掉的是反复渲染、传输和复制没变的内容。
我们没有拿这次记录去推算“上万篇也只要几秒”。没测过的规模，就先别替机器吹牛了。
更新完，还得看看读者能不能打开
文件传完，不能只看一句“成功”就收工。
这次发布先检查新内容，再切换到新的内容版本，同时保留旧版本，出问题时有回退依据。补齐后另做了一次全量线上检查，共 47 项通过，覆盖文章页面、图片和公共文件。
我们还查看了手机宽度下的页面：标题能换行，图片没有撑出屏幕。检查记录反映的是当时这些项目的结果，后续更新仍要验证。
至于 SEO，这次完成的是让网页有自己的地址、标题、摘要和网址清单。有这些资料，不代表搜索引擎已经收录，更不代表自然流量马上就来。 有没有被发现、有没有人读、能不能带来真实咨询，得继续看数据。
如果你也同时维护公众号和官网，可以先看自己的卡点在哪：是版本总对不上，旧图片重复上传，还是内容更新被绑在整个网站发布里？不一定一上来就买系统，先把最费事的那一步拆出来。
这次我们省下的，就是同一批内容反复打包搬家的活儿。稿件该确认还得确认，发布后该检查还得检查。让机器多搬点，人少折腾点，这就挺值。
记录日期：2026 年 11 月 2 日。本文依据本次实际迁移、增量发布与线上检查记录；具体数字仅对应本次测试。文末“阅读原文”可查看官网文章目录。