跨端开发中的逻辑共享与Monorepo实践

1. 跨端开发的痛点与逻辑共享的价值十年前我刚入行时前端开发还是jQuery一统天下的时代。那时候写个移动端页面往往需要为iOS和Android各准备一套代码。后来React Native和Flutter的出现让跨端开发成为可能但新的问题随之而来——业务逻辑的重复编写。上周我review团队项目时发现一个促销活动的倒计时逻辑在微信小程序、H5和React Native端分别实现了三次。这不仅浪费人力更可怕的是某次需求变更时只修改了两个平台而漏了第三个导致线上事故。这种各写各的的开发模式已经成为跨端项目最大的效率黑洞。逻辑共享的核心价值在于一致性保障避免不同平台出现行为差异维护性提升修改只需在一处进行开发效率减少重复劳动专注平台特有逻辑知识沉淀业务逻辑集中管理形成团队资产2. Monorepo逻辑共享的工程化基础2.1 什么是真正的Monorepo架构很多团队声称在用Monorepo但实际上只是把代码放在同一个git仓库里。真正的Monorepo应该具备原子化提交跨多个包/项目的修改能作为单一变更提交工作空间感知工具链能识别依赖关系图版本联动相关包可以同步发布版本依赖提升共用的第三方库会被自动hoist以我们电商项目为例目录结构是这样的packages/ ├── core/ # 纯业务逻辑 ├── h5/ # H5适配层 ├── mini-program/ # 小程序适配层 ├── native/ # React Native适配层 └── shared/ # 通用工具函数2.2 现代Monorepo工具选型经过对比测试我最终选择了这些工具链组合pnpm workspace比yarn/npm更高效的依赖管理Turborepo增量构建速度提升300%Changesets优雅的多包版本管理Nx强大的任务调度器适合大型项目配置示例turbo.json{ pipeline: { build: { outputs: [dist/**], dependsOn: [^build] }, test: { outputs: [], inputs: [src/**/*.test.ts] } } }3. 逻辑分层从UI下沉到环境解耦3.1 经典的三层架构实践Core层纯业务逻辑零平台依赖领域模型业务规则状态管理数据转换Adapter层平台适配API调用封装原生能力桥接组件Props转换UI层平台特有实现组件库样式系统交互逻辑以用户登录为例// core/auth.ts export class AuthService { async login(credentials) { // 纯业务逻辑不涉及任何平台API } } // adapters/wechat/auth.ts export class WechatAuthAdapter { constructor(private core: AuthService) {} async login() { const code await wx.login() return this.core.login({ platform: wechat, code }) } }3.2 环境解耦的进阶技巧依赖注入通过接口抽象平台能力interface Storage { getItem(key: string): Promisestring; setItem(key: string, value: string): Promisevoid; } class UserService { constructor(private storage: Storage) {} }编译时替换使用条件编译区分平台// webpack.config.js new webpack.DefinePlugin({ __PLATFORM__: JSON.stringify(process.env.TARGET) }) // 业务代码 if (__PLATFORM__ wechat) { // 小程序特有逻辑 }运行时适配动态加载平台模块const adapter await import(./adapters/${platform}/auth)4. 状态管理的共享策略4.1 跨端状态同步方案对比方案适用场景实现复杂度性能影响事件总线简单状态同步★☆☆☆☆★★☆☆☆状态中继中大型项目★★★☆☆★☆☆☆☆本地存储同步需要持久化的状态★★☆☆☆★★★☆☆WebSocket推送实时性要求高★★★★☆★★★☆☆4.2 推荐实现Zustand 中间件我们团队最终选择了Zustand方案原因在于极简API比Redux简单60%的样板代码原生支持React并发模式灵活的中间件系统核心实现// core/store/userStore.ts import create from zustand interface UserState { user: User | null login: () Promisevoid } export const useUserStore createUserState(set ({ user: null, login: async () { const user await authService.login() set({ user }) } })) // 小程序端适配层 const unsub useUserStore.subscribe(user { wx.setStorage({ key: user, data: user }) })5. 实战中的避坑指南5.1 平台差异的优雅处理处理微信小程序和H5的支付差异时我们采用了策略模式const paymentStrategies { wechat: (order) wx.requestPayment(order), h5: (order) fetch(/pay, { method: POST, body: order }) } async function pay(order) { const strategy paymentStrategies[__PLATFORM__] if (!strategy) throw new Error(Unsupported platform) return strategy(order) }5.2 类型安全的边界防护使用zod进行运行时类型校验import { z } from zod const UserSchema z.object({ id: z.string(), name: z.string().min(2), email: z.string().email() }) function updateUser(input: unknown) { const user UserSchema.parse(input) // 后续逻辑可以安全使用user对象 }5.3 性能优化关键点按需加载将核心逻辑拆分为多个chunk// vite.config.js build: { rollupOptions: { output: { manualChunks(id) { if (id.includes(core/)) return core } } } }缓存策略对计算密集型操作使用memoizationimport { memoize } from lodash-es const calculateDiscount memoize((price, coupon) { // 复杂计算逻辑 })树摇优化确保core层没有平台特定代码// package.json { sideEffects: false, type: module }6. 从逻辑共享到团队协作在落地逻辑共享方案时最大的挑战往往不是技术而是人。我们制定了这些协作规范代码所有权core层由架构组维护各端负责自己的适配层变更流程修改core逻辑需要双人review全平台测试文档规范所有共享API必须提供平台兼容性说明监控体系建立跨端一致性检查的自动化测试特别建议在项目初期就建立平台兼容性矩阵文档记录每个API在各平台的支持情况。这个文档后来成为了我们团队最重要的知识库之一。