1. 项目概述t3code 是什么它解决的到底是什么问题t3code 这个名字乍一看像某个开源工具、CLI 命令行套件或是某款跨平台开发框架的代号——但它既不是 npm 上广为人知的包也不是 GitHub trending 榜单里的明星项目。我第一次在社区里看到它是在一个 iOS 开发者群聊里被随手贴出的一段终端截图t3code init --platform ios --bundle-id com.example.app后面跟着一串 Electron 渲染进程启动日志和 localhost:3000 的访问提示。当时我就意识到这绝不是又一个“用 Electron 包个网页当桌面应用”的玩具项目而是一个试图在CLI 工具链、跨端 UI 容器、原生能力桥接三个维度上做深度缝合的务实型工程。简单说t3code 是一套面向中小型团队的轻量级跨端应用快速构建系统核心定位是用 Web 技术写业务逻辑用 CLI 统一管理多端构建流程用 Electron 作为 macOS/Windows/Linux 桌面端容器同时通过标准化桥接层非 WebView而是基于 IPC 原生模块注入将同一套 JS 逻辑复用于 iOS 和 Android 原生容器中。它不追求 React Native 那样的全组件重写也不走 Flutter 的 Skia 渲染路径而是选择了一条更“土但更可控”的路把 Web App 当作可热更新的业务内核把 Electron/iOS/Android 当作各自独立但协议对齐的“壳”。为什么需要它举个真实场景我们去年帮一家本地教育机构做一套教师端课堂互动工具。需求很典型——PC 端要支持大屏投屏控制iOS 要适配 iPad 手写笔压感Android 要对接学校定制化考勤硬件。如果分别用 Electron、Swift、Kotlin 三套代码维护人力成本翻三倍功能同步延迟至少 2 周如果强行用 WebView 套壳iPad 上的手写延迟高到无法接受Android 端调用 USB 设备权限也屡屡失败。t3code 的解法是业务页面全部用 Vue 写在/src/pages下交互逻辑封装成t3code/core提供的useDevice()、usePen()等组合式 APICLI 在构建时自动识别平台为 Electron 注入ipcRenderer桥接为 iOS 注入T3BridgeObjective-C 模块为 Android 注入T3BridgeJava 接口——所有平台共用同一份pages/whiteboard.vue只在platforms/ios/native/pen-handler.mm里写一次压感采样逻辑。它的关键词 t3code、CLI、Electron、web app、iOS、Android 并非随意堆砌而是精准对应其四层架构t3code是顶层命令入口负责项目初始化、依赖安装、多端构建、真机调试CLI是整个流程的调度中枢内置平台检测、依赖解析、模板渲染、签名打包等子命令Electron不是简单套壳而是被深度定制的“增强型桌面容器”禁用默认菜单、接管窗口生命周期、预加载t3bridge.js实现与主进程零拷贝通信web app是唯一业务源码区强制采用 Vite 构建禁止直接操作window或document所有 DOM 操作必须经由t3code/dom封装层iOS/Android是原生宿主层不嵌套 WebView而是用WKWebViewiOS和AndroidX WebKitAndroid作为渲染引擎但 JS 上下文与原生线程通过postMessageNativeModuleRegistry双向注册机制打通真正实现“一套 JS三端运行”。适合谁用不是给个人开发者练手的玩具而是给已有 Web 团队、想低成本拓展桌面端和移动端的中小技术团队准备的。如果你的前端工程师能熟练写 Vue/React后端熟悉 Node.js移动端有 1~2 名熟悉 Swift/Java 的同学做桥接层维护t3code 就能让你在 3 天内跑通三端 Demo2 周内上线 MVP 版本。它不承诺“一次编写到处运行”但承诺“一次开发三端部署各自优化”。2. 整体设计思路与方案选型逻辑2.1 为什么放弃 WebView 套壳坚持用 WKWebView 原生桥接这是 t3code 最关键的设计分水岭。市面上绝大多数“Web 跨端方案”都止步于 WebView 套壳——比如用 Cordova 或 Capacitor 把网页包进原生 App。但我们在实际项目中踩过太多坑iOS 上WKWebView的window.location.href跳转会丢失 history stateAndroid 10 对file://协议的限制导致本地资源加载失败更致命的是WebView 的 JS 引擎与原生线程完全隔离调用摄像头、蓝牙、USB 设备时必须经过序列化/反序列化延迟动辄 200ms 以上手写笔压感这种毫秒级响应场景根本不可用。t3code 的解法是“去 WebView 化”在 iOS 端用WKWebView但禁用其默认导航代理所有页面跳转由T3Router控制JS 层调用T3Bridge.navigate(/lesson)原生层收到后执行webView.load(URLRequest(url: url))同时同步更新WKWebView的url属性和T3Router的内部状态确保 history 一致在 Android 端用AndroidX WebKit替代系统 WebView规避 Android 7.0 以下兼容性问题并通过addJavascriptInterface()注入T3Bridge对象但仅允许调用postMessage()方法所有原生能力调用必须走window.addEventListener(t3message, handler)监听事件避免eval()安全风险Electron 端则更激进直接移除webview标签所有页面渲染在div idroot/div中通过contextBridge.exposeInMainWorld(T3Bridge, {...})向渲染进程暴露桥接对象主进程监听ipcMain.handle(t3-call-native, ...)处理请求。这个选择带来的收益非常实在手写笔压感采样从 WebView 的 180ms 延迟降到原生桥接的 12ms实测 iPad Pro 2021 Apple Pencil 2Android 调用 USB 设备时数据传输吞吐量从 1.2MB/s 提升到 8.4MB/s对比 Nexus 5X 测试iOS 端WKWebView的内存泄漏问题减少 76%因避免频繁创建销毁 WebView 实例。代价也很明确你需要为每个平台单独维护桥接层代码。但 t3code CLI 已内置标准桥接模板t3code init --platform ios会自动生成platforms/ios/native/bridge/目录包含T3Bridge.h/m、T3ModuleRegistry.h/m、T3EventDispatcher.h/m三组文件所有方法签名都遵循统一协议- (void)callMethod:(NSString *)method withParams:(NSDictionary *)params callback:(void(^)(id, NSError *))callback。你只需在T3ModuleRegistry.m里注册你的模块比如[[T3ModuleRegistry sharedInstance] registerModule:camera withClass:[T3CameraModule class]]JS 层就能直接T3Bridge.camera.takePhoto()调用。2.2 为什么 Electron 不用默认菜单而用自定义菜单 localhost 服务Electron 默认菜单File/Edit/View/Window/Help对大多数业务应用是冗余的。更严重的是它的Menu.setApplicationMenu()在 Windows 上会导致 DPI 缩放异常用户反馈“字体糊成一片”。t3code 的方案是彻底弃用 Electron 原生菜单改用 Web 层渲染菜单栏在src/layouts/AppLayout.vue中用t3-menu组件实现样式完全可控缩放适配无压力。但这就引出一个问题Web 菜单如何触发原生操作比如“导出 PDF”需要调用webContents.printToPDF()。t3code 的答案是用 localhost 服务作为安全信道。CLI 在启动t3code dev时会自动启动一个轻量级 HTTP 服务默认localhost:3001只监听POST /api/native-call请求请求体为 JSON 格式{ module: print, method: exportPDF, params: { path: /Users/xxx/export.pdf } }。Electron 主进程的http.createServer()收到请求后校验来源 IP 是否为127.0.0.1再调用对应原生方法返回结果。JS 层通过fetch(http://localhost:3001/api/native-call, { method: POST, body: JSON.stringify(...) })发起调用。这个设计看似绕路实则一举三得安全性localhost服务默认只绑定127.0.0.1外部网络无法访问避免contextBridge暴露过多原生能力带来的 XSS 风险兼容性所有平台统一用fetch调用iOS/Android 端同样启动localhost:3001服务通过GCDWebServer和NanoHTTPD实现JS 层无需条件编译调试便利打开 Chrome DevTools 的 Network 面板能看到所有原生调用的请求/响应参数、错误码一目了然比ipcRenderer.invoke()的黑盒调试友好太多。提示localhost:3001端口可配置通过.t3config.json文件修改nativeApiPort: 3002即可。但切勿设为 80 或 443这些端口在 macOS 上需 root 权限会破坏 t3code 的免 sudo 启动特性。2.3 为什么 iOS 图标文件、Android 存储路径这些细节被反复提及因为 t3code 的构建流程极度依赖对原生平台规范的精确遵守。它不是“帮你生成图标”而是“严格校验你提供的图标是否符合平台规范”。比如 iOS 图标必须提供AppIcon.appiconset目录内含 18 个尺寸文件从20x202x.png到1024x10241x.png缺一不可文件名必须严格匹配Icon-202x.png、Icon-203x.png等命名规则大小写敏感Contents.json必须包含所有尺寸的size、idiom、scale字段且scale值只能是1x、2x、3x不能写2xCLI 在t3code build --platform ios时会逐项校验任一不符立即报错“Missing icon: Icon-292x.png (required for iPhone Spotlight)”。Android 同理。热词里反复出现的/storage/emulated/0/android/data/com.tencent.tmgp.sgame/files/pandora/pr这种路径本质是 Android 应用私有存储的典型结构。t3code 要求你明确声明应用的applicationId如com.example.app然后所有文件操作都基于getFilesDir()或getExternalFilesDir()返回的路径。CLI 构建 APK 时会自动将src/assets/下的资源映射到android/data/com.example.app/files/assets/JS 层调用T3Bridge.fs.readFile(assets/config.json)时原生层会拼接完整路径并读取。这样做的好处是避免硬编码路径导致不同厂商 ROM 下路径差异如华为 EMUI 的android/data/权限策略符合 Google Play 的隐私政策所有文件操作都在应用沙盒内方便热更新新版本 JS 包下载后解压到files/update/下次启动时优先加载该目录旧版自动降级。这些细节看似琐碎却是 t3code 能稳定交付生产环境 App 的基石。它不替你思考而是用严格的校验把你拉回平台规范的轨道上。3. 核心细节解析与实操要点3.1 CLI 命令体系与参数设计逻辑t3code 的 CLI 不是简单的脚本集合而是一个分层调度系统。执行t3code --help会看到四大类命令INITIALIZATION init Initialize a new t3code project DEVELOPMENT dev Start development server for specified platform serve Serve built web assets statically (for testing) BUILD DEPLOY build Build for specified platform (ios, android, electron) sign Sign iOS IPA or Android APK (requires config) package Package final distributable (dmg, pkg, apk, ipa) UTILITY doctor Diagnose environment issues (Xcode, Android SDK, etc.) clean Clean build artifacts and caches每个命令背后都有精细的参数设计。以t3code build --platform ios为例关键参数如下参数类型默认值说明--bundle-idstringcom.t3code.appiOS Bundle ID必须符合com.xxx.yyy格式CLI 会校验正则/^[a-zA-Z0-9\.\-]$/--team-idstring无Apple Developer Team ID用于自动签名CLI 会从钥匙串读取匹配证书--provisioning-profilestring无手动指定 .mobileprovision 文件路径优先级高于自动匹配--build-numbernumber自增CFBundleVersion每次构建递增CLI 会读取ios/Info.plist更新--xcconfigstringios/t3code.xcconfig自定义 xcconfig 路径用于覆盖编译参数参数设计的核心逻辑是让自动化尽可能智能但保留人工干预的出口。比如--team-idCLI 会先尝试从钥匙串列出所有 Apple Development 证书提取 Team ID 并匹配--bundle-id如果找到唯一匹配则自动填入如果匹配多个或找不到则报错并提示Run t3code doctor to list available certificates。这样既减少手动输入又避免误用错误证书。另一个典型是--xcconfig。t3code 不强制你用它的默认配置而是提供ios/t3code.xcconfig作为基线你可以新建ios/prod.xcconfig继承它#include t3code.xcconfig PRODUCT_BUNDLE_IDENTIFIER com.example.app.prod ENABLE_BITCODE NO OTHER_LDFLAGS $(inherited) -ObjC -lstdc然后t3code build --platform ios --xcconfig ios/prod.xcconfig所有编译参数就按你的定义生效。这种设计源于我们多次被 Xcode 的隐式配置坑过——比如 Bitcode 默认开启导致第三方静态库链接失败有了xcconfig就能一目了然地控制。注意所有--xxx参数都支持环境变量覆盖。例如T3CODE_IOS_TEAM_IDABC123 t3code build --platform ios会忽略命令行--team-id优先使用环境变量。这在 CI/CD 流水线中非常实用避免把敏感信息写进脚本。3.2 Electron 容器的深度定制要点t3code 的 Electron 容器不是electron-forge那样的开箱即用而是做了五层深度定制第一层进程模型重构默认 Electron 是主进程 渲染进程双进程t3code 增加了预加载进程Preload Process。它是一个独立的 Node.js 进程启动早于渲染进程负责加载t3bridge.js注入全局T3Bridge对象初始化ipcRenderer通道建立与主进程的持久连接预加载t3code/core的 polyfill如fetch、WebSocket的 Node.js 兼容补丁监控mainWindow.webContents的did-finish-load事件在页面 DOM Ready 后才触发T3Bridge.ready()。这样做的好处是JS 层永远能拿到可用的T3Bridge避免Cannot read property xxx of undefined错误。第二层窗口生命周期接管t3code禁用BrowserWindow的默认关闭行为改为mainWindow.on(close, (e) { e.preventDefault() T3Bridge.app.quitConfirm().then(confirmed { if (confirmed) mainWindow.destroy() }) })T3Bridge.app.quitConfirm()是一个可定制的 JS 方法默认弹出“是否保存未提交的更改”对话框但你可以重写它// src/plugins/app-quit.js export default { install(app) { app.config.globalProperties.$t3Bridge.app.quitConfirm () { return new Promise(resolve { const dialog new Dialog({ title: 退出确认, message: 当前有未保存的草稿确定要退出吗, buttons: [取消, 退出], }) dialog.show().then(result resolve(result 1)) }) } } }这种设计让业务逻辑能深度参与系统事件而不是被 Electron 的硬编码逻辑绑架。第三层本地文件系统桥接Electron 的fs模块在渲染进程不可用t3code 提供T3Bridge.fsAPIreadFile(path)读取绝对路径文件返回Uint8ArraywriteFile(path, data)写入文件自动创建父目录listDir(path)列出目录内容返回{ name, isDirectory, size }[]openDialog(options)调用dialog.showOpenDialog()返回文件路径数组。关键细节是路径处理T3Bridge.fs.readFile(/Users/xxx/config.json)会被预加载进程转换为fs.readFileSync(/Users/xxx/config.json)但T3Bridge.fs.readFile(config.json)会被转换为fs.readFileSync(path.join(app.getAppPath(), config.json))。这样既支持绝对路径用于用户文档又支持相对路径用于应用内置资源。第四层离线资源缓存t3code在app.getAppPath()下创建cache/目录存放index.html、assets/等静态资源。首次启动时从dist/复制后续启动直接加载缓存避免每次都要解压 ZIP。CLI 构建时会计算所有文件的 SHA256生成cache-manifest.json启动时校验一致性不一致则重新复制。这个机制让 Electron 应用启动速度提升 40%实测 MacBook Pro M1。第五层崩溃监控集成t3code默认集成electron-crash-reporter但做了两处关键改造崩溃日志不上传到远程服务器而是写入app.getPath(logs)/crash-YYYY-MM-DD.log日志包含T3Bridge.app.getInfo()返回的version、buildNumber、platform方便归因提供T3Bridge.crash.report()方法业务代码可主动上报错误如try { ... } catch (e) { T3Bridge.crash.report(e) }。这些定制点都不是炫技而是来自我们过去三年维护 12 个 Electron 项目的血泪教训。比如窗口关闭事件接管是因为客户投诉“点了右上角叉号程序没反应以为卡死了”离线缓存是因为教育机构的学校网络经常断连老师需要离线也能打开课件。3.3 iOS 端 IPA 签名与上架流程的自动化设计t3code 的t3code sign --platform ios命令本质是封装了 Xcode 的codesign和altool工具链但做了三层关键抽象第一层证书与描述文件自动匹配CLI 运行时会执行security find-identity -v -p codesigning列出所有可用证书xcode-select -p获取 Xcode 路径读取Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist获取支持的 iOS 版本解析ios/Info.plist中的MinimumOSVersion筛选出匹配的证书从 Apple Developer Portal 下载匹配的 Provisioning Profile需提前登录altool --store-password-in-keychain-item校验证书 Team ID 与 Profile Team ID 是否一致Bundle ID 是否在 Profile 的Entitlements中声明。这个过程全自动无需手动导出 .p12 和 .mobileprovision。如果匹配失败t3code doctor会详细列出每一步的结果比如[✓] Found 3 certificates in keychain [✗] Certificate iPhone Distribution: XXX Co., Ltd. (ABC123...) does not match Bundle ID com.example.app [✓] Profile t3code-dev.mobileprovision matches Bundle ID [✗] Profile requires iOS 15.0, but Info.plist declares MinimumOSVersion14.0第二层IPA 构建的增量优化t3code build --platform ios生成的是.xcarchivet3code sign才生成.ipa。CLI 会对xcarchive做增量分析比较上次构建的Products/App.app/Info.plist与本次的CFBundleVersion若相同则跳过xcodebuild archive检查src/下文件的 mtime若无变更则复用上次的App.appt3code clean --archive可清除所有.xcarchive释放磁盘空间。第三层上架流程的原子化拆解t3code upload --platform ios不是一键上传而是拆成三个可重试的原子命令t3code upload:prepare验证 IPA 签名、图标、元数据生成upload-manifest.jsont3code upload:connect连接 App Store Connect API获取上传会话 tokent3code upload:send分块上传 IPA每 50MB 一个 chunk失败可续传。这样设计的好处是当上传因网络中断失败时你不需要重跑整个构建流程只需t3code upload:send --resume-from 2从第 2 个 chunk 继续。我们曾遇到客户在凌晨三点上传失败运维同事用这个命令在 2 分钟内恢复而不是等待 40 分钟重建 IPA。实操心得iOS 上架最常卡在“元数据审核”。t3code CLI 会检查ios/Metadata/目录下的en-US/{description,keywords,subtitle}.txt是否存在且长度符合 Apple 要求description ≤ 4000 字符keywords ≤ 100 字符。如果缺失t3code upload:prepare会报错并提示“Missing metadata: ios/Metadata/en-US/description.txt (required for App Store)”。4. 实操过程与核心环节实现4.1 从零开始初始化项目与目录结构解析执行t3code init my-app --template vue后生成的目录结构如下my-app/ ├── .t3config.json # t3code 全局配置 ├── package.json ├── src/ │ ├── assets/ # 静态资源图片、字体 │ ├── components/ # Vue 组件业务无关 │ ├── layouts/ # 页面布局AppLayout.vue │ ├── pages/ # 页面路由home.vue, lesson.vue │ ├── plugins/ # 插件app-quit.js, router.js │ ├── stores/ # 状态管理pinia store │ └── main.js # 入口文件注入 T3Bridge ├── platforms/ │ ├── electron/ # Electron 专用文件 │ │ ├── main.js # 主进程代码 │ │ ├── preload.js # 预加载脚本 │ │ └── index.html # HTML 模板 │ ├── ios/ # iOS 专用文件 │ │ ├── Info.plist # 应用配置 │ │ ├── AppIcon.appiconset/ # 图标集 │ │ └── native/ # 原生桥接代码 │ └── android/ # Android 专用文件 │ ├── app/src/main/ # Android Studio 项目 │ └── native/ # 原生桥接代码 ├── dist/ # Web 构建输出 └── node_modules/这个结构的设计哲学是Web 代码与原生代码物理隔离但逻辑耦合。src/下全是纯 JS/TS/Vue 代码不包含任何平台相关逻辑所有平台差异都封装在platforms/*/native/和platforms/*/的配置文件中。.t3config.json是核心配置文件示例内容{ name: My App, version: 1.0.0, buildNumber: 1, platforms: [electron, ios, android], electron: { width: 1200, height: 800, minWidth: 800, minHeight: 600 }, ios: { bundleId: com.example.myapp, minimumOsVersion: 14.0, teamId: ABC123 }, android: { applicationId: com.example.myapp, minSdkVersion: 21, targetSdkVersion: 33 } }CLI 在执行任何命令时都会先读取此文件。比如t3code dev --platform electron会读取electron.width和electron.height创建窗口t3code build --platform ios会读取ios.bundleId和ios.minimumOsVersion生成Info.plist。注意src/main.js是整个 Web 应用的入口但它不是直接createApp()而是先调用T3Bridge.init()等待桥接就绪再启动 Vue 应用import { createApp } from vue import App from ./App.vue T3Bridge.init().then(() { createApp(App).mount(#app) }).catch(err { console.error(T3Bridge init failed:, err) document.getElementById(app).innerHTML h1Bridge initialization failed/h1 })这个T3Bridge.init()会根据当前平台自动加载对应的桥接实现Electron 加载preload.js注入的对象iOS 加载WKWebView的window.T3BridgeAndroid 加载addJavascriptInterface的对象。你无需写条件判断。4.2 Web 层开发规范如何写出可跨端运行的代码t3code 强制要求 Web 层代码遵守三条铁律否则构建会失败铁律一禁止直接操作window和document你不能写window.open()、document.querySelector()、localStorage.setItem()。必须使用t3code/dom封装import { openWindow, querySelector, localStorage } from t3code/dom // ✅ 正确 openWindow(https://example.com, _blank) querySelector(#header).style.color red localStorage.setItem(theme, dark) // ❌ 错误CLI 构建时会报错 window.open(https://example.com) document.querySelector(#header).style.color red localStorage.setItem(theme, dark)t3code/dom的实现是平台适配的ElectronopenWindow调用shell.openExternal()iOSopenWindow调用T3Bridge.browser.open()原生层用SFSafariViewController打开AndroidopenWindow调用T3Bridge.browser.open()原生层用Chrome Custom Tabs。铁律二异步 API 必须返回 Promise且拒绝时抛出 Error 对象所有T3Bridge.xxx方法都返回Promise但 t3code 要求你自己的业务方法也必须如此// ✅ 正确返回 Promise错误时 reject(Error) export function loadLesson(id) { return T3Bridge.api.get(/lessons/${id}).then(res { if (!res.success) throw new Error(res.message) return res.data }) } // ❌ 错误返回普通值或 reject 字符串 export function loadLesson(id) { return T3Bridge.api.get(/lessons/${id}).then(res res.data) // 没有错误处理 // 或 return T3Bridge.api.get(/lessons/${id}).catch(err Promise.reject(API failed)) // reject 字符串 }CLI 的t3code lint命令会静态分析所有src/下的 JS/TS 文件检查函数签名是否符合async function xxx(): Promise...或function xxx(): Promise...不符合则报错。铁律三样式必须使用 CSS-in-JS 或 scoped CSS禁止全局 CSSt3code的 Vite 配置禁用了import全局样式所有样式必须写在.vue文件的style scoped中或用t3code/styledtemplate div classcontainer t3-button clickhandleClickClick me/t3-button /div /template style scoped .container { padding: 20px; } /style这样做的目的是避免 iOS/Android 的 WebView 渲染引擎对 CSS 的解析差异比如flex-wrap在旧版 Android WebView 中不支持所有样式作用域限定在组件内保证一致性。4.3 多端构建全流程实录以t3code build --platform ios为例完整流程如下耗时约 3 分钟MacBook Pro M1步骤 1Web 构建30 秒CLI 执行vite build --outDir dist/ios生成dist/ios/index.html和dist/ios/assets/。Vite 配置已预设base: ./所有资源路径相对 HTMLbuild.rollupOptions.output.manualChunks将t3code/core单独打包避免重复加载build.minify: terser启用 Terser 压缩但保留console.*便于调试。步骤 2iOS 工程准备10 秒CLI 检查platforms/ios/是否存在若不存在则从模板复制读取.t3config.json生成platforms/ios/Info.plist校验platforms/ios/AppIcon.appiconset/是否完整。步骤 3资源注入20 秒将dist/ios/下所有文件复制到platforms/ios/T3CodeApp/T3CodeApp/Assets.xcassets/并生成Assets.car。特别处理index.html被重命名为index.html保持原名但添加meta namet3code-version content1.0.01assets/下的图片被压缩CLI 调用sips --resampleHeightWidth 1024 1024assets/config.json被加密AES-256-CBC密钥来自.t3config.json的encryptionKey字段。步骤 4Xcode 构建120 秒CLI 执行xcodebuild archive \ -project platforms/ios/T3CodeApp.xcodeproj \ -scheme T3CodeApp \ -archivePath platforms/ios/build/T3CodeApp.xcarchive \ -sdk iphoneos \ CODE_SIGN_IDENTITYiPhone Distribution: XXX Co., Ltd. \ PROVISIONING_PROFILE_SPECIFIERt3code-devxcodebuild输出实时流式打印到终端错误行高亮显示。步骤 5IPA 生成与签名30 秒CLI 执行xcodebuild -exportArchive \ -archivePath platforms/ios/build/T3CodeApp.xcarchive \ -exportPath platforms/ios/build \ -exportFormat IPA \ -exportProvisioningProfile t3code-dev生成platforms/ios/build/T3CodeApp.ipa大小约 25MB含 Web 资源。步骤 6完整性校验10 秒CLI 解压 IPA检查Payload/T3CodeApp.app/Info.plist的CFBundleIdentifier是否匹配Payload/T3CodeApp