分类： 动态快报

后端：不要直接复用默认接口

WordPress 自带的 REST API 能直接返回文章、分类、评论等数据，但默认返回的字段是面向通用场景的：包含大量小程序用不到的字段（编辑器相关、作者详细信息等），既增加传输体积，也暴露不必要的信息。

因此建议在服务端做一层面向小程序的输出接口：要么注册自定义接口，要么对既有接口的输出做裁剪与补充。需要处理的三件事：

• 字段裁剪：只保留小程序渲染真正需要的字段（标题、摘要、封面、发布时间、分类、阅读数等）；
• 字段补充：把小程序需要的派生信息在服务端算好（如格式化后的时间、分类名称数组），减少前端计算；
• 结构统一：把不同内容类型的数据结构对齐，避免前端为每种类型写一套解析逻辑。

跨域、鉴权与缓存

跨域：小程序端的请求不受浏览器同源策略限制，但若同一套接口还要供 H5 使用，就必须在服务端正确配置跨域响应头，并明确允许的来源、方法与请求头，不要图省事一律放开。

鉴权：公开内容走匿名访问即可；涉及用户数据（收藏、积分、订单）的接口必须带身份凭证。常见做法是登录后由后端签发令牌，前端在请求头中携带，服务端对每个敏感接口逐一校验，而不是依赖前端判断。

缓存：内容型接口读多写少，适合缓存。建议按内容类型设置不同的缓存时效——列表类接口短缓存保证时效，详情类接口可适当延长；同时在内容更新时主动失效相关缓存，避免用户长时间看到旧数据。

数据契约：先约定，再编码

前后端并行开发时，接口结构必须先约定并文档化。约定内容至少包括：字段名与类型、可空性、时间格式、分页参数与返回结构。实践中容易踩的坑有几个：

• 可空字段未标注：作者信息有时是对象、有时是字符串、有时为空，前端按对象取值就会报错；
• 分页结构不统一：不同接口的列表返回结构不一致，前端要写多套解析；
• 类型不一致：数字与字符串混用（如 ID 有时是数字有时是字符串），比较与索引时出错。

前端：结构规范化与容错兜底

前端不应假设后端一定返回完整、正确、符合预期的数据。建议在请求层统一做两件事：

1. 结构规范化：把接口返回的数据在进入页面之前统一转换成页面期望的契约——缺失的字段补默认值，可空字段统一成一种类型，列表字段保证是数组而非 null；
2. 安全取值：模板中避免直接访问可能不存在的深层属性，改用返回安全默认值的方法或可选链取值，确保个别字段缺失时页面不白屏。

同时注意请求层的统一封装：统一处理加载中、失败重试与错误提示，避免每个页面各写一套；对失败请求给出可理解的提示，而不是把原始错误直接抛给用户。

小结

用 WordPress 作为小程序后端的价值在于复用成熟的内容管理能力，而工程风险集中在两处：服务端的输出裁剪与鉴权、前端的数据规范化与容错。接口结构约定清楚、异常情况有兜底，这条链路才能长期稳定运行，而不会因为某个字段偶尔为空就整页报错。

为什么必须用子主题

直接修改父主题的问题很直接：父主题一更新，改动全部被覆盖；若不更新，又要独自承担安全与兼容风险。子主题解决了这个两难——父主题负责基础结构与功能并可持续升级，子主题只承载站点的定制部分。

一个最小可用的子主题只需要一份样式表（在头部注释中声明模板来源）与一个函数文件。样式的引入方式需要注意：若是简单叠加，直接引入父主题样式表；若要按需覆盖，则需理解父主题的加载顺序，确保自定义样式在其之后生效。

需要澄清一个常见误解：子主题不能覆盖父主题的模板逻辑（除非在子主题中提供同名模板文件）。因此子主题的适用范围是“样式与轻量逻辑定制”，涉及结构改动的复杂需求，需要通过钩子或替换模板文件来完成。

钩子怎么选，优先级怎么定

WordPress 的钩子分两类，用途截然不同：

类型	作用	典型用途
Action（动作）	在某个时点插入或执行逻辑	在页面头部插入代码、注册资源、保存文章时同步数据
Filter（过滤器）	接收数据、修改后返回	修改查询参数、输出内容、菜单结构、摘要长度

选择依据很清楚：要“做一件事”用 action，要“改一份数据”用 filter。误用会导致逻辑不生效或产生意外副作用。

优先级决定同一钩子上多个回调的执行顺序，数值越小越先执行。实践建议：

• 不写默认值（默认 10）时要明确意识到顺序不可控，依赖前序结果时显式指定优先级；
• 避免极端数值（如 0 或 9999），除非确有需要抢先或垫底；
• 移除父主题的某个回调时，必须使用与其相同的优先级，否则移除会失败。

代码如何组织

二次开发容易在长期迭代后变成“什么都在 functions.php 里”。可控的组织方式是按职责分文件：

child-theme/
├── functions.php          仅做加载与装配
├── inc/
│   ├── assets.php         资源注册与加载
│   ├── hooks-filter.php   内容与查询过滤器
│   ├── hooks-action.php   时点动作逻辑
│   └── helpers.php        通用辅助函数
└── template-parts/        局部模板覆盖

约定几条红线：函数名统一加前缀，避免与父主题或插件冲突；辅助函数只做一件事；不在模板文件中写业务逻辑，模板只负责输出。这样即使中途换人接手，也能按文件职责快速定位。

小结

子主题与钩子共同构成一道“可升级 + 不侵入”的防线：前者让改动与父主题解耦，后者让逻辑与模板解耦。再配合明确的分文件组织与命名前缀，WordPress 主题的二次开发就能从“一次性交付”变成可持续维护的工程实践。

先理解区块的标准结构

无论哪个区块插件，其区块都遵循 Gutenberg 的通用结构：一个区块通常由描述文件（元信息、属性定义、支持的样式）、编辑态实现（编辑器内如何呈现与配置）与保存态实现（前端如何输出）构成。理解这一层结构，是判断“哪些地方可以扩展、哪些地方不能碰”的前提。

Getwid 的区块同样基于这套结构，并对区块属性做了大量封装。它的源码是插件的一部分，升级时会整体替换——这一点决定了二次开发的基本策略：只扩展，不篡改。

可用的扩展点在哪里

区块插件的二次开发，扩展点大致分四类，按侵入性从低到高排列：

1. 区块样式变体：为标准区块或已有区块注册新的样式预设，用户可在编辑器侧边栏切换。适合纯视觉定制，零侵入；
2. 过滤器与钩子：通过 WordPress 的过滤器修改区块的输出、属性或允许的区块类型。适合调整行为与结构；
3. 自定义区块：以独立插件的形式注册新块，满足 Getwid 未覆盖的内容需求；
4. 直接修改插件文件：仅在别无他法时使用，且必须记录改动以便升级后重新应用——不推荐作为常规手段。

实践中的选择顺序是：能用样式变体解决就不写过滤器，能用过滤器解决就不建新块。

新增自定义区块的落地方式

新增区块建议做成独立的二级插件，而不是放进主题的 functions.php。原因有三：主题切换后区块仍可用；区块注册与主题解耦，职责清晰；便于版本管理。

落地时的要点：

• 使用官方提供的脚手架工具初始化区块工程，产出标准目录结构（区块源码、构建产物、区块元信息）；
• 编辑器内的输入属性与前端呈现要保持同一份数据来源，避免“编辑器看着对、前端输出不对”；
• 编辑态样式与前端样式分开编写，编辑器样式不要被打包进前端资源；
• 为区块设置合理的默认属性值与占位内容，保证刚插入时编辑器可预览。

改造既有区块的注意事项

如果只需要对既有区块做局部调整（例如增加一个可选字段、调整输出结构），优先走过滤器与样式变体。需要特别注意的是保存态兼容：修改区块的保存输出会导致老内容校验失败、编辑器提示“内容由未知区块产生”。规避方式是保持已发布区块的保存结构不变，新字段通过服务端渲染或输出过滤器追加。

升级兼容策略

插件升级是二次开发的最大变量。建议做到三点：

• 隔离：所有定制代码放在自有插件或子主题中，与插件本体物理隔离；
• 锁定与预演：生产环境不自动更新插件，升级前先在测试环境验证定制是否受影响；
• 留痕：改动集中在少数文件，并在文档中记录每处改动对应的扩展点，升级后可按图索骥逐项回归。

小结

区块插件的二次开发有一条清晰的分界线：扩展点之上尽情发挥，插件本体之内绝不越界。掌握样式变体、过滤器与自定义区块三类手段，并配合隔离与预演机制，就能在享受插件生态的同时，保住站点定制的长期可维护性。

先量化：把“慢”拆成可定位的指标

“打开很慢”不是可执行的结论。动手之前，先把体验拆成几个可测量的指标：首字节时间（TTFB，反映服务端与网络链路）、首次内容绘制（FCP，反映首屏可见时间）、最大内容绘制（LCP，反映主要内容加载完成时间），以及交互延迟相关指标。

数据来源分两类，两者都要看：

• 实验室数据：用性能审计工具在受控环境下跑分，便于复现与逐项对比，但不代表真实用户；
• 真实用户监控（RUM）：采集真实访客在不同网络与设备上的表现，反映分布情况，但单次采集噪声较大。

实验室数据用来定位问题，真实用户数据用来验证效果，两者混用会导致误判。

七个手段与作用层级

序号	手段	作用层级	主要改善
1	图片优化（压缩、现代格式、按尺寸加载、懒加载）	资源	传输体积与 LCP
2	资源压缩与精简（CSS/JS 压缩、去除未使用代码）	资源	传输体积与解析时间
3	缓存策略（浏览器缓存、页面缓存、对象缓存）	服务端与客户端	TTFB 与重复访问速度
4	CDN 与就近分发	网络	全球访问的 TTFB
5	首屏关键路径优化（关键 CSS 内联、字体加载策略、非关键脚本延迟）	渲染	FCP 与 LCP
6	数据库与查询优化（慢查询、索引、减少重复查询）	服务端	TTFB
7	渲染与交互优化（减少重排重绘、长列表虚拟化、骨架屏）	渲染	交互流畅度与感知速度

优先级排序的依据是“收益 ÷ 成本”。多数站点上，图片与缓存两项往往能解决大部分问题，应优先处理；数据库与查询优化取决于站点后端的实际结构；渲染细节则往往在最后打磨。

优化中的取舍

性能优化不是“越极致越好”，需要权衡：

• 缓存与时效：缓存时间越长，性能越好，但内容更新的可见延迟越大，需要按内容类型分别设定；
• 内联与复用：把关键 CSS 内联能加快首屏，但会牺牲跨页缓存复用，需按页面结构权衡；
• 懒加载与体验：过度懒加载会让用户在滚动时看到大片空白，得不偿失；
• 第三方脚本：统计、客服、地图等功能会显著拖慢页面，应按需精简而不是默认全上。

持续监控，防止回退

性能优化不是一次性项目。一次改版、一个新插件、一张未压缩的图片都可能让成果退回原点。建议把关键指标纳入常规巡检：定期跑一次审计并与基线对比；上线新功能前后各测一次；把资源体积阈值写进构建流程，超标时给出提示。

小结

性能优化的正确顺序是测量 → 定位 → 分层治理 → 回归验证。先确认瓶颈在哪一层，再选择对应手段，最后用同一套指标验证效果。把“从 3 秒到 1 秒”当作目标区间而非口号——目标值应结合业务与用户网络环境确定，并靠持续监控守住。

从业务目标倒推信息架构

信息架构（IA）不是把内容分门别类，而是决定访客按什么顺序获得信息。因此起点不是“我们有什么内容”，而是“访客来这里要完成什么”。

企业官网的访客通常带着几类意图：了解你们是谁、判断你们能解决什么问题、评估是否值得联系。对应的内容优先级是：

1. 价值主张：一句话说明做什么、为谁做、有什么不同；
2. 能力证明：服务/产品条目、技术与方法论、可验证的成果形式；
3. 信任建立：团队、案例的呈现方式（注意公开信息边界）、合作流程；
4. 转化入口：联系与咨询路径，需在任何页面可达。

把意图排成序，导航结构自然浮现：一级导航对应意图，二级导航对应意图下的分支。导航项之间应是并列关系，而不是包含关系——把“服务”和“服务中的某一项”放在同一级，是常见的结构错误。

内容优先级与导航设计

确定优先级后，需要把它落到层级深度与入口密度上：

• 层级不超过三级：常规官网内容量下，超过三级后到达率会明显下降；
• 重要内容就近可达：核心转化入口不应只出现在页脚；
• 导航名称用用户语言：用“能解决什么问题”的说法，而不是内部部门或产品代号；
• 首页承载分流而非堆料：首页的职责是让访客快速判断“我该去哪一页”，而不是把所有内容都铺上去。

视觉规范如何落地到组件层

视觉规范脱离组件就没有约束力。要让规范真正生效，至少要把以下内容沉淀为可复用的资产：

规范项	落地形式
颜色	定义为主题变量（主色、辅助色、语义色），页面不写死色值
字号与行高	定义排版层级（标题/正文/辅助文字），避免逐页手调
间距	采用统一的间距刻度，保证页面节奏一致
组件	按钮、卡片、表单控件做成可复用组件，含各状态样式

关键在语义化命名：把变量命名为“主色”“危险色”“正文色”，而不是“蓝色”“红色”。这样后续整体换肤只需改变量值，不必逐页查找替换。

典型误区

• 先做首页视觉稿，再考虑内容结构：导致结构迁就排版，新增内容时难以扩展；
• 导航按内部组织架构划分：访客不理解公司内部如何分工；
• 视觉规范只交付设计稿，不交付变量与组件：开发只能凭肉眼对数值，规范很快失效；
• 过度追求动效：动效服务于信息层级时才有效，为动而动会拖慢首屏并分散注意力。

小结

信息架构解决“找得到”，视觉规范解决“维护得住”。前者从访客意图倒推，后者以主题变量与组件为载体落地。两者都做扎实，官网才能在内容持续增长的条件下保持结构清晰、风格统一。

接手第一步：先摸清现状，再动手

接手存量站点，第一件必须做的事不是看代码，而是建立一份改动前快照：完整文件备份 + 数据库导出 + 记录当前的插件/主题版本号。这份快照既是回滚依据，也是判断“问题是否由本次改动引入”的对照基线。

第二步是列出改动清单：站点正在使用哪些主题与插件、哪些是官方原版、哪些已被前手改过。区分“原版”与“改过”的方式通常是版本号与文件的修改时间比对，必要时与官方版本做逐文件 diff。

八个高频坑与规避动作

1. 不备份就动手。直接在生产环境改文件，出错后无基可退。规避：改动前必须完成文件与数据库双备份，并在本地或测试环境先行验证。
2. 直接修改父主题。父主题一升级，所有自定义改动被覆盖。规避：一律通过子主题承载改动。
3. 在插件源码上打补丁。插件更新即丢失，且升级后行为不一致。规避：优先使用插件提供的钩子或过滤器扩展，确需改动时用独立插件覆盖其行为。
4. 全局搜索替换改样式或文案。看似高效，实则误伤同名变量、函数与字符串。规避：改动限定在明确文件内，替换前先预览匹配结果，逐项确认。
5. 忽略环境差异。本地与线上 PHP 版本、数据库版本、启用的扩展不一致，导致“本地正常、线上报错”。规避：改动前核对两端环境参数，并把环境要求写进交接文档。
6. 忽略缓存层。改完看不到效果，误判为改动失败，进而重复修改。规避：明确站点是否启用页面缓存、对象缓存与 CDN，改动后按既定流程清缓存再验证。
7. 未评估影响面就改结构。修改数据库字段、内容类型或公共钩子，牵动大量既有页面。规避：先检索该结构被引用的位置，列出受影响清单，再决定改动方式。
8. 没有改动记录与回滚方案。改动完成后无人知道改了什么、为什么改。规避：每次改动都记录文件、原因与影响范围，重要改动配套回滚步骤。

如何建立可持续的二次开发规范

单个坑可以靠细心避免，但持续交付要靠规范。几条可落地的约定：

• 改动收敛：所有自定义逻辑集中在子主题与自研插件中，形成“可识别的自有代码区”；
• 版本留痕：用版本管理工具承载代码，提交信息写清改动目的，而非只写“修改”；
• 升级预演：主题或插件升级前，先在测试环境验证自定义部分是否仍生效；
• 交接文档：记录环境参数、插件清单、已做改动与已知问题，让下一位接手者不必重新考古。

小结

二次开发的本质是“在一个不完全了解的系统中做有边界的改动”。先备份、再评估、后动手，把改动限制在自有代码区并留下记录，绝大部分坑都可以提前规避。技术上的难点通常可控，不可见的历史改动才是真正的风险来源。

可直接落地的几条心理学原理

可用性领域有不少被反复验证的规律，其中几条对前端引导最直接有用：

• 希克定律：选项越多，决策时间越长。适用于表单、导航、按钮组的数量控制；
• 菲茨定律：目标越大、越近，越容易被命中。适用于高频按钮的尺寸与位置安排；
• 接近性原则：空间上靠近的元素被认为相关。适用于表单标签与输入框、错误提示与出错字段的绑定；
• 曝光效应：反复接触会提升好感与熟悉度。适用于关键入口的稳定位置——不要频繁挪动主操作。

这些原理的价值在于：它们把「感觉界面怪」翻译成可检查的具体项。

视觉层级：先看什么，后看什么

用户不会阅读页面，而是扫视页面。因此设计的第一步是确定「第一眼看到什么、第二眼看到什么」，再用对比度、字号、留白把它固化下来。

实践建议：

• 一个页面只有一个最强视觉焦点，通常是主操作按钮或核心信息；
• 次级信息通过降低对比度弱化，而不是通过缩小字号到不可读；
• 同一屏内颜色语义保持一致（主色=可操作，灰色=不可用，红色=风险），避免同一颜色承担多种含义。

如果用户需要「想一下才知道点哪里」，说明层级设计没有完成。

默认选项与渐进披露

降低决策成本最有效的手段有两个：给默认值、分步骤。

默认选项：把最符合多数人预期的选项设为默认，用户可以改但不必须改。默认值本质上是一种「推荐」，但要注意——如果默认选项对用户不利（如默认勾选付费），短期数据可能好看，长期会显著损害信任。

渐进披露：把低频、复杂、非必要的字段或设置折叠起来，只在用户表达相关意图时展开。典型场景是高级筛选、批量操作与详细设置。原则是「常用可见、罕用可找」，而不是把所有能力都摊在主界面上。

引导设计的边界：过度引导的三种表现

引导一旦过度，会从「帮助用户」变成「干扰用户」。以下三种表现值得警惕：

• 弹窗泛滥：新手引导、问卷、活动弹窗在短时间内连续弹出，用户的第一反应是找关闭按钮，而不是看内容；
• 强制路径：把用户必须完成的操作设为「不可跳过」，而这些操作对当下目标并无必要；
• 诱导性默认与暗黑模式：用视觉误导让用户点击非预期按钮，或把关闭入口做得难以发现。

判断标准可以归结为一句话：引导的目标是让用户少想，而不是让用户按我们的意愿行事。前者是可用性，后者只是转化率短期数字。

小结

把心理学原理用进前端交互，关键不在记住名词，而在于把它转化为可执行的检查项：选项数量是否克制、视觉焦点是否唯一、默认值是否对用户有利、引导是否可以被跳过。做到这几点，界面的说服力来自它的清晰，而不是来自提示的密度。

冷启动：先解决「有没有人说话」

社区最怕的不是人少，而是空场。新用户进来看到「最新回复：无」，几乎必然离开。因此冷启动的产品目标不是拉多少人，而是保证任一时刻，每个主要版块都有可读、可回应的内容。

可行的做法有几条：

• 控制版块数量：宁可先开 3 个能持续产出内容的版块，也不要一次开 20 个都是空的；
• 准备可回应的内容：把常见问题做成结构化主题，降低后来者「插一句话」的心理门槛；
• 把新用户引导到有内容的路径：首页默认展示「最近有回复」的主题，而不是按时间倒序的空白列表。

冷启动阶段最忌讳的是用工具批量灌水。灌进去的内容与真实讨论无关，反而会稀释社区调性，且一旦被用户识别，信任成本极高。

留存靠什么：内容供给与关系链

留存机制常见的三种抓手是内容、关系与激励，三者的持久度并不相同。

机制	作用原理	持久度
内容供给	用户为获取信息而回访	中，取决于内容更新频率与质量
关系链	用户为关注的人、讨论的话题而回访	高，迁移成本随关系积累上升
激励机制	用户为积分、等级、勋章而行为	低，激励一旦停止行为随之消失

实践中的顺序是：先用内容把人留下来，再用关系把留下的人绑住，激励只作为补充。关系链的技术支撑包括关注、私信、@提醒、回复通知——这些功能的价值不在功能本身，而在于它们让「人与人之间的互动」变得可预期。

激励机制的定位与边界

积分与等级不是不能用，但要清楚它能做什么、不能做什么。它能启动行为：让新用户完成首次发帖、资料补全这类一次性动作。它很难维持行为：一旦激励消耗完毕，纯粹为积分而来的用户会迅速流失。

因此设计激励时建议遵循两条：一是奖励产出而非奖励动作（获得有效回复的帖子比单纯发帖更有价值）；二是设置上限与冷却，避免刷量行为污染内容池。

指标怎么看：口径先统一

指标的意义建立在口径一致之上。若今天按「登录」算活跃、明天按「发帖」算活跃，任何趋势判断都不可信。建议先把几个基础口径固定下来：

• 次留：某日新增用户中，次日有任意有效行为的比例；
• 7 留：某日新增用户中，第 7 日仍有有效行为的比例；
• DAU / MAU：日活与月活之比，用于观察用户回访的黏性；
• 有效行为必须明确列举（如浏览内容、发布、回复、点赞），不能含糊表述为「使用产品」。

口径一旦确定就写进文档，后续所有报表都引用同一份定义。

小结

社区运营是产品设计与运营节奏的配合：冷启动阶段靠可控的内容准备度过空场期，成长期靠内容与关系链形成回访习惯，指标则用来验证前两者是否真的生效。激励可以锦上添花，但不应被当作留存的支柱。

先划边界：自研还是用插件

会员体系的复杂度分三块：用户身份与登录、会员等级与权益、权限校验。前两块与 WordPress 的用户系统、角色体系高度重合，成熟插件已覆盖大部分通用需求；第三块与业务强绑定，往往是插件最难满足的部分。

因此建议的划分是：身份与等级用成熟能力，权限校验与业务规则自研。具体判断标准有三条：

• 会员分层规则是否与业务强耦合（如按订单、按积分、按邀请关系）？
• 是否需要与站内内容类型做细粒度映射（如某分类仅某等级可见）？
• 是否存在插件无法覆盖的定制流程？

只要有一条为「是」，就应当把相应的校验逻辑握在自己手里，而不是硬塞进插件配置。

会员分层与内容权限

分层设计的关键是把「等级」与「权益」解耦。等级是用户属性，权益是内容属性，两者通过一张映射表关联，而不是把等级判断写死进模板。

• 内容侧：给文章/页面增加一个「可见性」字段（公开、登录可见、指定等级可见）；
• 用户侧：用户挂载一个等级标识；
• 校验侧：统一由一个函数判断「当前用户能否查看该内容」，所有模板和接口都调这个函数。

这样做的好处是：新增等级只改映射表，不触碰模板；日后要改成「按订阅状态判断」，也只需替换校验函数的实现。

支付接入的落地路径

支付接入可以统一为四步，与具体支付通道无关：

• 下单：后端生成站内订单记录（含订单号、金额、状态），先落库再调通道；
• 请求支付参数：调用通道接口换取拉起支付所需的参数，交由前端发起；
• 接收异步回调：通道回调到达后端，必须先验签，确认请求来源可信；
• 更新订单与权益：验签通过后更新订单状态，并发放对应权益。

这里有两个不可省略的点：验签与幂等。验签防止伪造回调；幂等防止通道重复推送导致权益被重复发放——实现方式通常是以订单号做唯一约束，重复请求直接返回成功而不重复发货。

权限校验应该放在哪一层

这是最容易出问题的地方。原则只有一条：客户端不做权限裁定。

前端可以隐藏入口、置灰按钮，这是体验优化；但真正的校验必须发生在服务端——无论是页面渲染前的钩子，还是接口返回前。原因很直接：前端的一切判断都可以被绕过，只有服务端是可信边界。

实践上建议在校验函数里同时处理三件事：未登录返回登录引导、等级不足返回明确提示、内容不存在与无权限不作区分（避免通过枚举探测内容是否存在）。

小结

会员与支付不是「装个插件就完事」的功能，而是涉及信任链的工程问题。把等级与权益解耦、把校验统一收口到服务端、把验签与幂等做在回调链路上，这三件事做扎实，剩下的才是运营层面的玩法设计。

坑的本质：三端对同一能力的实现并不一致

多端框架解决的是「语法统一」，不是「行为统一」。同一个业务动作，三端底层可能是完全不同的接口：微信有 wx.login，抖音有 tt.login，App 侧则要走手机号或第三方 OAuth。组件同样如此，button 上挂的 open-type 取值集合在各端并不相同。

因此适配的重点不是「少写代码」，而是让差异有唯一出口。

高频差异清单

差异类型	典型表现
组件属性	button 的 open-type 取值不同；canvas、video 的属性与事件名存在差异
平台 API	登录、支付、分享、订阅消息、剪贴板等接口名与返回结构不同
生命周期	冷启动/热启动时 onLaunch 与 onShow 的时序在各端略有差异
样式与布局	安全区适配、自定义导航栏高度、状态栏高度的获取方式不一致

把这些差异列成清单并落成文档，比记在个人经验里可靠得多——因为清单可以交给下一位接手的同学。

隔离方案：条件编译 + 运行时探测

差异处理分两类：

1. 编译期就能确定的差异（「这段逻辑只在微信端存在」）：用条件编译处理。

// #ifdef MP-WEIXIN
return weixinShare(options)
// #endif
// #ifdef MP-TOUTIAO
return toutiaoShare(options)
// #endif

2. 编译期无法确定的差异（同一端内还存在设备或版本差异）：用运行时能力探测，例如通过 uni.canIUse() 判断 API 是否可用、读取 uni.getSystemInfoSync().uniPlatform 判断运行平台，在不支持时降级而不是报错。

两条原则：不在页面里直接出现 wx.、tt. 前缀；所有端差异统一收敛到 utils/platform 网关，页面只调用网关暴露的统一函数。

三条关键链路怎么处理

• 登录：各端先拿到临时凭证（微信 code、抖音相应票据），统一由后端换取会话标识，前端只负责「拿凭证 → 调后端 → 存 token」。凭证校验逻辑必须放在后端，前端不参与。
• 支付：统一为三步——前端向后端请求支付参数、调用各端支付 API 拉起收银台、后端接收异步回调并验签。前端只负责发起与结果提示，订单状态以后端回调为准，不能以客户端返回为准。
• 分享：各端的参数结构不同（标题、图片、路径的键名不一致），因此要封装成统一入参对象，再由网关按端转换，避免每个页面各写一套。

工程约束与验证方式

除隔离规则外，还有两条约束值得写进团队规范：一是新增端必须走网关，不允许在业务代码中直接判断平台；二是每次发版对三端做一轮冒烟，重点验证登录、支付、分享三条链路，因为这三处最容易在框架升级后出现行为漂移。

小结

多端适配的成本不在「写一次」，而在「差异隔离得是否干净」。把端差异收敛到少数几个文件、把关键链路的责任边界划清（前端负责发起、后端负责裁定），一套代码才能真正跑稳在多个端上，而不是每接一个端就重做一遍。