Uni-app 同时发小程序和 App，平台差异越堆越多，2026 年从哪一步开始收？

Uni-app 跨端开发遇到平台差异，不建议一套手法用到底：差异是点状的、只影响一行渲染或一个 API 参数时，条件编译更省事；差异成片出现、在多个页面反复出现时，就该抽适配层或拆平台专属文件。按 2026 年项目交付经验，单页条件编译分支在十处以内通常还能接受，一旦同一能力在三个以上页面重复出现，继续硬堆分支，维护成本常见区间会超过“少写一份代码”省下的量。

平台差异先分三类，再决定写到哪

跨端差异通常集中在三类：渲染呈现层（样式、单位、组件层级、安全区）、平台能力层（登录、支付、分享、定位、文件、推送）、结构层（页面栈、分包、路由参数、生命周期触发顺序）。三类差异的收敛方式不同，混在一起处理就会越改越乱。

判断依据是差异会不会扩散：只影响单个组件的一次渲染，算点状；同一能力在两端 API 名称或返回结构不同，算面状；页面拆法、导航方式、平台审核规则导致的结构不同，算体状。点状差异用条件编译成本低，体状差异用条件编译就是给自己埋坑。

• 点状：单位换算、个别样式覆盖、单个 API 参数不同
• 面状：登录、支付、分享、定位等能力的调用方式与返回结构不同
• 体状：页面结构、分包策略、导航与平台审核规则差异
• 判断口径：同一处差异只出现一两次按点状处理，在三个以上页面反复出现按面状或体状处理

差异散落为什么比“少写一份代码”更耗工期

跨端框架省的是重复编码，不会省掉差异本身。2026 年常见的交付组合是“小程序为主、App 为辅、再加少量 H5 活动页”，三端并行时真正吃掉工期的不是写页面，而是差异散落导致每次改需求都要回头确认“这段在别的端会不会崩”。差异集中之后，改一处只影响一处。

另一个现实是，AI 辅助编码普及后，生成页面样式的成本明显下降，能把平台差异收敛成清晰接口的人反而更稀缺，因为工具很难替你判断某条分支该不该长期留在业务代码里。

• 差异散落：每次变更都要全端回归，测试成本成倍上升
• 差异集中：一个能力域对应一个适配文件，改完只回归该能力
• 交接角度：新人看适配层目录，就知道哪些功能存在平台差异
• 反面情况：模板里的条件编译没有注释，接手人只能猜哪端生效

分流三步法：先问能不能收敛，再决定写到哪一层

不少工程不是方案选错，而是顺序错了：一开始就用条件编译，等差异积累到几十处才想重构，此时改动面已经很大。可以按下面顺序处理。

1. 定性：判断差异属于渲染层、能力层还是结构层。渲染层优先用样式隔离或单位换算解决，不急着写分支。
2. 看能否收敛成接口：同一能力多端语义一致、只是实现不同，就抽成统一方法（统一登录、统一存储、统一请求），调用方不感知平台。
3. 看密度：只出现一两处的点状差异就地条件编译；同一能力在三个以上页面出现走适配层；页面结构与导航不同走平台专属文件或分包页面。
4. 留痕：每处平台分支写清“为什么”和“哪端生效”，条件编译块超过一屏就拆成函数。

两点注意：适配层要薄，只做协议转换，别把业务逻辑塞进去；平台专属文件不要复制整页再改，共用部分抽出去，否则后续改需求要改两遍。

交付现场：差异散落带来的那次返工

项目里常见的一种情况是预算有限、周期压在四到六周（经验区间，随页面数量浮动），团队先按 H5 写完再往小程序和 App 上套，条件编译直接写在页面模板里，前期确实快。到上线前三端回归时，才发现登录态在 App 端读不到缓存、分享参数在小程序端丢失，而这两处差异分散在七八个页面里，只能逐页排查，返工大约多花两到四人日（经验区间），联调节点也往后推了两天。代价不在代码量，而在“没人说得清哪些页面受影响”。

三种做法放一起怎么比

三种做法不是对错关系，而是适用区间不同。判断时看差异密度、可测试性和后续改动频率，别只看当下写起来快不快。

• 条件编译：适合点状差异，改动快、上手低；缺点是分散、不便独立测试，密度高时维护成本上升，常见适用于单页十处以内的改动（经验区间）
• 适配层封装：适合面状能力差异，一次封装多端调用；每个能力域前期约多花零点五到两人日（经验区间），换来业务代码干净、可单测
• 平台专属文件或分包页面：适合体状结构差异，隔离彻底；代价是同类逻辑可能重复，需要有人维护共用部分
• 体积维度：条件编译对包体积影响小，平台专属文件会略微增加，触及小程序主包限额时优先考虑分包或按需引入

验收口径与适用边界

差异管理好不好，可以用几条可核对的口径判断，不必凭感觉。

• 条件编译块带注释说明平台与原因，单块不超过一屏（经验口径）
• 同一能力在业务层只有一处入口，不出现“页面里直接写两端 API”
• 新增一端时改动集中在适配层与少量结构文件，业务页面基本不动
• 三端回归清单可枚举，接手人能据此复现差异点
• 平台分支没有到处复制，改需求时不需要“改两遍”

适合：同时交付小程序和 App（或再加 H5），差异集中在登录、支付、分享、定位等能力域；需求会持续迭代、多人接手、回归成本敏感的项目。不太适合：只发一个端，或一次性活动页，两三处条件编译即可收尾；差异本来能靠统一设计规范消除的，先改规范比写分支更省。边界句：跨端框架减少的是重复编码，不会消除平台差异；差异管理是工程决策，不是框架自带功能。

常见问题

条件编译写多少算多？

按经验区间，单页超过十处，或同一能力在三个以上页面重复出现，就建议抽适配层，而不是继续加分。

Uni-app 的适配层通常放什么？

主要放协议转换：把多端 API 的差异收敛成统一入参出参，业务判断留在页面或状态管理层。

拆平台文件会不会让代码量翻倍？

共用逻辑抽到 composable 或工具函数后，平台文件只保留差异部分，常见做法下增量在一到两成（经验区间）。

小程序主包超限时先改哪里？

先看图片资源与第三方库，再看是否把非首屏页面改成分包；平台判断类代码一般不是体积大头。

一个人维护多端，建议用哪种做法？

优先适配层加少量条件编译，复杂结构差异再拆平台文件；单人维护时怕的是差异散落在页面里。

下一步可以这样落地：新项目在搭目录时就把适配层位置定下来，先覆盖登录、存储、请求、埋点这四类高频能力；老项目不必一次重构，按“新需求走新规则、旧差异随改动迁移”推进。若只发一个端或页面数量很少，继续用条件编译即可，不必为此加一层。把差异集中是为了少回归，不是为了多写代码。