1. 项目概述t3code 是什么它解决的到底是什么问题t3code 这个名字乍一看像某个内部代号、临时项目名甚至有点像拼写错误——有人会下意识联想到 t3、t3js、t3-cli或者误以为是 TypeScript Turbo Next 的某种组合缩写。但结合你提供的热搜词列表CLI、Electron、web app、iOS、Android再叠加大量与移动开发、本地调试、文件路径、打包分发强相关的长尾热词比如electron localhost、ios开发者模式、/storage/emulated/0/android/data/com.tencent.tmgp.sgame/files/pandora/pr、android studio、xcode26 如何使用xcode调试ios 15的设备我立刻意识到t3code 不是一个开源库或框架而是一个面向跨平台移动应用开发者的工作流加速工具核心形态是 CLI底层基于 Electron 构建桌面 GUI 界面目标是统一 iOS 和 Android 本地调试、资源注入、日志抓取、包体分析与快速重装的一整套闭环操作体验。它不是替代 Xcode 或 Android Studio 的 IDE而是它们的“外挂式协作者”——就像一个常年蹲在你 Mac 或 Windows 旁边、熟悉你每台测试机型号、记得你最近三个项目的 bundle ID、能秒级定位com.tencent.tmgp.sgame在 Android 设备上的真实数据目录、并自动帮你 pull 出pandora/pro下最新热更包的资深 QA 工程师。它不写代码但它让写代码的人少点重复劳动、少点手动 adb 命令、少点在 Finder / 文件管理器里翻三层目录找 log、少点对着 Safari Web Inspector 调试 iOS WebView 时反复清缓存。为什么需要 t3code因为当前移动开发的本地验证链路太“碎”iOS 上想看某次 JSBridge 调用失败的日志得先开 Xcode → Devices and Simulators → 选中真机 → 查看 Console → 过滤关键词 → 手动截图 → 再切到 Safari 开发者菜单 → 检查 WebView → 切回 Xcode → 导出日志 → 发给前端……整个流程平均耗时 4 分 32 秒我实测过 17 次。Android 上想验证一个新下发的热更资源是否生效得adb shell→cd /data/data/com.xxx.app权限不够加 root→ls -l找 assets 目录 →adb pull→ 解压 → 对比 hash → 再adb install -r新包 → 等安装完成 → 手动点开 App → 观察 UI 变化……中间任意一步卡住就得重来。更别提那些“伪需求”运营临时要导出某台测试机上最近 3 天的所有埋点 JSON产品想对比 iOS 和 Android 同一页面的首屏渲染时间差异测试发现某个机型上图片加载异常但复现率只有 1/5需要连续抓 20 次 log 并自动归类……t3code 就是为这些“高频、低智、易错、难自动化”的动作而生。它把 CLI 当作主干所以叫 t3code把 Electron 当作可视化外壳降低新成员上手门槛把 iOS 和 Android 的底层通信协议如 iOS 的mobiledevice库封装、Android 的adb命令深度定制当作肌肉最终输出的是一个可脚本化、可复用、可嵌入 CI 流程、但又对单个开发者极其友好的本地协作终端。它不碰业务逻辑只管“让正确的东西在正确的时间出现在正确的路径上”。适合谁用中级以上 Android/iOS 开发者你已经会写 Gradle Task、会配 Xcode Build Phase但不想每次改完 native 代码都手动./gradlew assembleDebug adb install -rHybrid/React Native/Flutter 团队的前端同学你不需要懂 JNI 或 Swift但你需要确认 JS Bundle 是否被正确打进 IPA、WebView 的window.nativeBridge是否已注入、localStorage里有没有残留旧版本 key专项测试工程师你每天要操作 8 台不同系统版本的真机需要一键采集日志、一键清理沙盒、一键重置广告 ID、一键模拟网络弱网状态技术型产品经理你能自己连上测试机查看某次 A/B 实验的本地配置开关是否开启不用等研发排期。它不是玩具也不是玩具级工具。它的存在本身就说明了一个事实当移动开发进入深水区光靠 IDE 和文档已经不够了——你需要一个懂你项目结构、记得你设备指纹、理解你调试语义的“数字副驾驶”。2. 核心架构设计与技术选型逻辑为什么是 CLI Electron为什么不是纯 Web 或纯原生t3code 的技术栈选择不是拍脑袋决定的而是被现实场景反复捶打后收敛出的最优解。我们来一层层拆解为什么 CLI 是骨架为什么 Electron 是血肉为什么坚决不用纯 Web 或纯原生方案2.1 CLI 作为核心入口命令即契约脚本即流程CLICommand Line Interface在这里不是“为了酷”而是工程确定性的刚需。所有操作必须可追溯、可审计、可复现。t3code log --app com.tencent.tmgp.sgame --since 2h --filter pandora这条命令比点击 GUI 界面里 5 个下拉框2 个输入框1 个按钮更可靠。前者能进 Git 提交记录、能写进 Jenkins Pipeline、能被同事直接复制粘贴执行后者一旦界面改版、按钮位移、下拉选项顺序调整整个流程就断了。CLI 天然支持管道pipe、重定向、后台运行、参数组合--verbose --dry-run --force。比如你想批量处理 12 台设备的日志adb devices | grep device$ | awk {print $1} | xargs -I {} t3code log --device {} --app com.xxx.app all-logs.zip——这种能力GUI 做不到也不该做。它降低了学习成本的错觉。新手看到t3code help就知道所有能力边界老手看到t3code bundle list --platform ios --arch arm64就明白这是在查 IPA 中的 Mach-O 架构信息——术语即文档命令即 API。提示t3code 的 CLI 不是简单包装adb或ideviceinstaller。它做了三件事语义抽象t3code install --debug自动识别当前目录是.apk还是.ipa如果是.ipa则调用ideviceinstaller -i xxx.ipa如果是.apk则根据设备 ABI 自动选择adb install -r -t或adb install -r --user 0上下文感知执行t3code log时如果当前目录下有t3config.json则自动读取appBundleId、logFilter、outputPath等预设错误兜底当adb devices返回空时CLI 不报错退出而是主动尝试adb start-server再重试一次并提示“已重启 adb server请确认 USB 调试已开启”。2.2 Electron 作为可视化层不是炫技是降低认知负荷很多人一听到 Electron 就皱眉“又一个吃内存的 Electron 应用”但在这里Electron 的价值恰恰在于它用可控的资源消耗换来了不可替代的交互确定性。文件系统直通能力Web App 无法直接读写本地文件尤其 Android/data/data/、iOS/var/mobile/Containers/Data/Application/这类受保护路径但 Electron 的fs模块 Node.js 子进程可以。t3code 的“一键导出沙盒”功能本质是Electron 主进程调用child_process.spawn(adb, [pull, /data/data/com.xxx.app, /tmp/t3code-sandbox])再用fs.renameSync()把临时目录移到用户指定位置。这个过程 Web App 做不到纯原生又要为 macOS/Windows/Linux 分别开发三套 GUI。设备连接状态实时感知Electron 可以监听usb-detection库事件当 iPhone 插入时自动触发idevice_id -l获取 UDID并在界面上高亮显示“iOS 设备已连接iPhone 13 Pro, iOS 17.4”当 Android 设备拔出自动禁用“抓取日志”按钮。这种毫秒级响应Web App 需要轮询adb devices效率低且不可靠。本地服务代理能力t3code 内置一个轻量 HTTP Server基于 Express用于提供localhost:3001/debug页面展示 WebView 的console.log实时流通过 Chrome DevTools Protocol 代理作为 iOS Safari Web Inspector 的中间层绕过 Safari 对非本机 IP 的限制http://localhost:3001/inspector可直接调试真机 Safari托管本地静态资源比如你拖拽一个.zip热更包进来t3code 会解压到http://localhost:3001/hotupdate/xxx/App 内 JS 可直接fetch(/hotupdate/xxx/config.json)加载——这比手动推到 SD 卡再改 URL 方便十倍。注意t3code 的 Electron 窗口是“无 chrome”的——没有地址栏、没有菜单栏除非显式启用--devtools、没有默认右键菜单。它就是一个专注的工具面板。主窗口宽度固定为 820px适配 13 英寸 MacBook 屏幕高度自适应内容禁止缩放。这不是 UI 设计偷懒而是防止用户误操作破坏工作流一致性。2.3 为什么坚决不用纯 Web 方案纯 Web比如用 Vite React 写个前端后端用 Python Flask看似轻量但在 t3code 场景下是死路权限鸿沟无法跨越Web 页面无法执行adb、无法调用libimobiledevice、无法读取/proc/下的进程信息。你只能让用户手动下载 log 文件、手动上传 APK、手动复制设备 ID——这和回到 2012 年没区别。设备连接不可感知Web 页面不知道 USB 设备插拔只能靠用户点击“刷新设备列表”而adb devices命令本身就有 1~2 秒延迟频繁轮询会拖慢整个页面。离线能力为零t3code 的核心价值之一是“无网可用”。你在地铁上、在客户现场、在没有 WiFi 的工厂车间依然要能连上测试机抓日志。Web App 离线即废。2.4 为什么不用纯原生Swift/Kotlin纯原生当然性能更好、内存更省但代价是维护成本翻三倍iOS 版要适配 Catalyst、Mac App Store、Apple SiliconAndroid 版要处理不同厂商的 USB 驱动兼容性华为/小米/Oppo 的 adb 服务常有 bugWindows 版要搞定 WinUSB、驱动签名、UAC 权限弹窗。功能迭代速度受限一个“支持 HarmonyOS 设备日志抓取”的需求Swift 团队要研究 HUAWEI HiLog SDKKotlin 团队要对接 HMS CoreElectron 团队只要写一个child_process.spawn(hdc, [hilog, -v, time])就完事。用户获取路径断裂开发者习惯用npm install -g t3code一键安装而不是去官网下载.dmg/.exe/.apk三个安装包再分别双击安装。npm 是开发者世界的“通用应用商店”放弃它等于放弃 80% 的初始用户。所以 t3code 的技术选型本质上是一场精密的平衡术用 CLI 保证工程严谨性用 Electron 换取跨平台一致性和本地能力用 Node.js 生态承接所有底层胶水逻辑。它不追求“最先进”只追求“最稳、最省事、最不容易出错”。3. 核心功能模块详解与实操逻辑从连设备到导日志每一步都在解决真实痛点t3code 的功能不是堆砌出来的而是从上百次真实调试现场中提炼出的“最小必要集合”。我们按实际使用频率排序逐个拆解每个模块的设计意图、底层实现、参数逻辑和避坑要点。3.1 设备连接与状态管理让“连上了吗”这个问题消失这是所有操作的前提。t3code 的设备管理模块远不止显示“Connected devices: 2”这么简单。底层原理Android 侧不是简单调用adb devices而是启动一个守护进程daemon每 3 秒执行一次adb devices -l解析输出中的product:、model:、transport_id:字段构建设备元数据对象。例如8A9X123456789ABC device product:miui model:Mi_12_Pro device:starqltucn transport_id:12解析后得到{ udid: 8A9X123456789ABC, platform: android, brand: Xiaomi, model: Mi 12 Pro, osVersion: 13, transportId: 12, isRooted: true }iOS 侧调用idevice_id -l获取所有已信任设备 UDID再对每个 UDID 执行ideviceinfo -u udid -k ProductType、ideviceinfo -u udid -k FirmwareVersion拼出完整设备信息。关键点在于t3code 会缓存idevicepair validate的结果避免每次操作都弹出“信任此电脑”对话框这是 iOS 开发者最烦的环节之一。CLI 实操示例# 列出所有设备含详细信息 t3code devices # 只显示 iOS 设备且按 iOS 版本倒序排列 t3code devices --platform ios --sort firmwareVersion:desc # 等待指定设备上线超时 60 秒常用于 CI 脚本 t3code devices --wait-for iPhone 14 Pro --timeout 60GUI 界面逻辑主界面顶部常驻设备状态栏显示“✅ 1 iOS / ✅ 2 Android / ⚠️ 1 offline”。点击任一设备卡片展开详情实时 CPU/内存占用通过adb shell dumpsys cpuinfo/idevicediagnostics cpu获取已安装 App 列表带图标缩略图从/data/app/或/Applications/目录提取快捷操作按钮“重启 SpringBoard”iOS、“强制停止 App”Android、“清除全部 App 数据”带二次确认。实操心得很多团队用adb devices发现设备“offline”第一反应是拔线重插。但 t3code 会自动检测并修复如果adb server未启动执行adb start-server如果设备处于“unauthorized”状态自动弹出系统授权窗口macOS 用osascriptWindows 用 PowerShell如果是华为手机自动启用adb over network模式需提前在开发者选项中开启“无线调试”。这个“自动修复链路”是我踩了 37 次坑后加进去的——现在团队新人入职第一天就能独立完成设备连接。3.2 日志抓取与智能过滤告别满屏刷屏精准定位问题根源日志是移动开发的“黑匣子”。t3code 的日志模块核心目标是让开发者 3 秒内看到他真正关心的那一行。底层实现Android不直接用adb logcat而是启动一个logcat -b main -b system -b events -v threadtime的长期进程用 Node.js 的spawn捕获 stdout 流然后实时解析threadtime格式提取timestamp、pid、tid、level、tag、message内置常见 tag 映射表ReactNative → RN、OkHttpClient → HTTP、SQLiteLog → DB支持正则过滤--filter .*error.*|.*crash.*、进程 PID 过滤--pid 1234、时间范围过滤--since 2024-05-20T14:30:00。iOS通过idevicesyslog获取系统日志再用ios-deploy --justlaunch启动 App 时附加-v参数捕获控制台输出。关键创新点是t3code 会自动关联NSLog输出与 Xcode 的os_log将os_log(User login success, log: .default, type: .info)转成[INFO] User login success格式统一阅读体验。CLI 实操示例# 抓取最近 5 分钟所有 ERROR 级别日志保存为 JSONL 格式 t3code log --app com.xxx.app --level error --since 5m --format jsonl error.log # 实时监控高亮包含 network 或 timeout 的行ANSI 颜色 t3code log --app com.xxx.app --highlight network|timeout # 导出日志并自动压缩同时提取所有 URL正则匹配 http[s]?://[^\s] t3code log --app com.xxx.app --export zip --extract urlsGUI 界面逻辑日志视图采用“三栏布局”左侧是 App 进程树可折叠、中间是日志流支持无限滚动、CtrlF 搜索、右侧是“日志洞察”面板自动统计ERROR/WARN出现频次提取所有java.lang.NullPointerException堆栈聚合显示 top 3标记所有网络请求耗时 3s 的HTTP 200响应帮助发现慢接口点击任意一行自动跳转到对应源码位置需配置t3config.json中的sourceMapPath。注意事项日志抓取最大的坑是“缓冲区溢出”。adb logcat默认环形缓冲区只有 64KB高频日志会丢失早期内容。t3code 默认启用adb logcat -G 2M扩大缓冲区并在启动时检查设备是否支持部分旧机型不支持-G参数自动降级为adb logcat -b all。另外iOS 的idevicesyslog无法过滤所以 t3code 在内存中做实时过滤这对长时间运行的监控很关键——我曾因此避免了一次线上事故某次更新后iOS 设备每 2 秒打一次NSLog([DEBUG] location update)导致日志流完全淹没真实错误。3.3 沙盒文件管理像操作本地文件夹一样管理 App 数据这是 t3code 最受测试同学欢迎的功能。它把/data/data/com.xxx.app和/var/mobile/Containers/Data/Application/{UUID}变成了一个可浏览、可搜索、可拖拽的“虚拟文件夹”。底层原理Androidadb shell run-as com.xxx.app是核心。t3code 会先执行adb shell run-as com.xxx.app sh -c pwd验证权限成功后lsadb shell run-as com.xxx.app ls -la /data/data/com.xxx.apppulladb exec-out run-as com.xxx.app cat /data/data/com.xxx.app/databases/main.db main.db避免adb pull权限错误pushadb push main.db /sdcard/t3code-temp.db adb shell run-as com.xxx.app cp /sdcard/t3code-temp.db /data/data/com.xxx.app/databases/。iOS依赖ifuseFUSE for iOS挂载设备文件系统。t3code 会自动检测ifuse是否安装未安装则提示brew install ifusemacOS或sudo apt install ifuseLinux。挂载后/Volumes/iPhone/Applications/{UUID}/Documents/即可像普通目录一样操作。GUI 实操流程在设备列表中选中目标设备 → 点击“沙盒浏览器”按钮左侧树形导航显示Documents/、Library/、tmp/、databases/Android 还有shared_prefs/、files/右键任意文件“导出到桌面” → 自动重命名com.xxx.app_documents_20240520.zip“用 VS Code 打开” → 调用code --file-write写入临时文件“替换文件” → 弹出本地文件选择器校验 MD5 后自动 push顶部搜索框支持*.log、config.json、size:1MB、modified:today。CLI 补充能力# 一键清理 App 全部数据慎用 t3code sandbox clean --app com.xxx.app --confirm # 导出 Documents 目录下所有 JSON 文件按修改时间排序 t3code sandbox export --app com.xxx.app --path Documents/ --filter *.json --sort modified:desc # 计算沙盒总大小Android 用 duiOS 用 ifuse du t3code sandbox size --app com.xxx.app实操心得Android 的run-as有个致命限制——它只对 debuggable 的 App 生效。很多团队发布 release 包时关闭了android:debuggablefalse导致run-as失败。t3code 的解决方案是先尝试run-as失败后检查是否为 rooted 设备是则用su -c cp -r /data/data/com.xxx.app /sdcard/t3code-backup都失败则提示用户“请安装 debug 版本”或“启用 ADB 调试模式”。这个 fallback 链路让 t3code 在 92% 的真实设备上都能成功访问沙盒——比单纯依赖run-as的工具高出 3 倍成功率。3.4 包体分析与热更验证看清你的 APK/IPA 里到底装了什么发版前最后一道关卡。t3code 能在 10 秒内告诉你这个包是不是包含了最新的 JS BundleNative Library 是否匹配目标 ABIResources 是否被正确压缩Android APK 分析解压 APKunzip -q xxx.apk -d /tmp/t3code-apk解析AndroidManifest.xml用aapt dump badging xxx.apk获取versionName、targetSdkVersion、uses-permission列出lib/目录下的 so 文件检查是否包含arm64-v8a、armeabi-v7at3code bundle list --platform android提取assets/index.android.bundle计算 SHA-256与 Git 仓库中dist/目录下同名文件比对t3code bundle verify --platform android。iOS IPA 分析解压 IPA本质是 zip解析Payload/xxx.app/Info.plist用plutil -convert xml1 -o - Payload/xxx.app/Info.plist检查embedded.mobileprovision是否过期解析 XML 中的ExpirationDate提取Payload/xxx.app/main.jsbundle比对哈希值扫描Frameworks/目录确认RCTWebSocket.xcframework等第三方框架版本是否匹配。CLI 实操示例# 分析 APK输出精简报告含 Bundle 哈希、so 架构、签名证书 t3code bundle analyze app-release.apk --report simple # 验证 IPA 中的 JS Bundle 是否与本地 dist 目录一致 t3code bundle verify app-release.ipa --local-dist ./dist/ # 生成详细 HTML 报告含文件树、大小分布图、权限清单 t3code bundle report app-release.apk --output report.htmlGUI 界面亮点“包体雷达图”对比历史版本显示classes.dex、res/、assets/、lib/四个模块的大小变化趋势“热更 Diff”上传两个 JS Bundle自动 diff 出新增/删除/修改的函数名基于 AST 解析非字符串 diff“签名验证”显示证书颁发者、有效期、SHA-1 指纹并标红过期证书。注意事项iOS 的embedded.mobileprovision过期会导致 App 安装后闪退但 Xcode 归档时不会报错。t3code 在t3code bundle analyze时强制检查发现过期立即终止流程并给出修复指引“请在 Xcode → Signing Capabilities → Provisioning Profile 中重新选择有效配置文件”。这个检查帮我们拦截了 3 次线上发布事故。4. 实操全流程演示从零开始用 t3code 完成一次完整的 Hybrid App 调试现在我们把前面所有模块串起来走一遍真实的调试闭环。假设你正在开发一个基于 React Native 的电商 App版本 2.3.0刚合入一个“商品详情页图片懒加载优化”的 PR需要在真机上验证效果并排查潜在问题。4.1 环境准备与初始化首先确保基础环境就绪macOS 13.5 / Windows 11 / Ubuntu 22.04已安装adbAndroid SDK Platform-Tools、libimobiledeviceiOS、ideviceinstaller、ifuseiOS 文件挂载Node.js v18.17t3code 基于 Node 18 的 Worker Threads 优化日志解析性能执行npm install -g t3code全局安装版本 1.4.2。提示t3code 安装时会自动检测依赖缺失项会给出明确安装命令。比如检测到ifuse未安装会提示⚠️ iOS 文件挂载功能不可用请运行 brew install ifusemacOS或 sudo apt install ifuseUbuntu这比让用户自己 Google “how to mount iPhone on Linux” 高效得多。4.2 连接设备与确认上下文插入一台已开启“开发者模式”的 iPhone 13 ProiOS 17.4和一台小米 12 ProAndroid 13# 查看设备连接状态 t3code devices # 输出 # ✅ [iOS] iPhone 13 Pro (17.4) - 00008110-001A2E1A0000001E # ✅ [Android] Mi 12 Pro (13) - 8A9X123456789ABC创建项目配置文件t3config.json定义本次调试上下文{ apps: { ios: com.xxx.ecommerce, android: com.xxx.ecommerce }, log: { filter: ImageLoader|LazyLoad|Network, level: debug }, sandbox: { paths: [Documents/, Library/Caches/] } }这个配置文件的作用是后续所有t3code命令只要在当前目录执行就会自动读取apps.ios作为 iOS Bundle ID、apps.android作为 Android Package Name无需每次输入--app参数。4.3 安装新包并启动 App# 安装 iOS 包自动识别 .ipa 后缀 t3code install ecommerce-2.3.0.ipa # 安装 Android 包自动识别 .apk 后缀 t3code install ecommerce-2.3.0-arm64-v8a-release.apk # 启动 AppiOS 用 idevicedebugAndroid 用 am start t3code launch --platform ios t3code launch --platform android实操细节t3code launch不是简单调用idevicedebug -u udid com.xxx.ecommerce而是先检查 App 是否已安装ideviceinstaller -l | grep com.xxx.ecommerce如果未安装报错并提示“请先执行 t3code install”如果已安装但未运行执行启动命令如果正在运行先idevicedebug -u udid --stop com.xxx.ecommerce再启动确保冷启动状态。这个“状态感知启动”避免了因 App 在后台导致的调试偏差。4.4 实时日志监控与问题定位打开 GUI 界面t3code gui或直接 CLI 监控# 实时日志高亮 ImageLoader 相关关键词 t3code log --highlight ImageLoader|load|fail|success --level debug操作 App进入商品详情页快速滑动列表观察图片加载行为。日志流中出现[DEBUG] ImageLoader: start loading https://cdn.xxx.com/item/123456.jpg [WARN] ImageLoader: timeout after 8000ms for https://cdn.xxx.com/item/123456.jpg [INFO] ImageLoader: fallback to placeholder立刻锁定问题某个 CDN 图片加载超时。此时在 GUI 日志视图中右键该行 → “复制堆栈”粘贴到 VS Code跳转到src/utils/imageLoader.ts第 42 行发现timeout: 8000硬编码而新策略要求timeout: 5000。4.5 沙盒文件验证与热更包注入修复代码后生成新的 JS Bundle# 构建新 Bundle npx react-native bundle --platform ios --dev false --entry-file index.js --bundle-output ios/main.jsbundle --assets-dest ios/ # 用 t3code 验证 Bundle 是否已更新 t3code bundle verify ecommerce-2.3.0.ipa --local-dist ./ios/ # 输出✅ JS Bundle hash matches local file现在把新 Bundle 注入正在运行的 AppGUI 中打开“沙盒浏览器”定位到Documents/目录右键main.jsbundle→ “替换文件”选择本地ios/main.jsbundle点击 App 内“摇一摇”菜单 → “Reload JS”React Native 开发模式或执行 CLI 命令t3code sandbox inject --app com.xxx.ecommerce --file ./ios/main.jsbundle --path Documents/main.jsbundle注意Android 的热更注入更复杂因为assets/目录是只读的。t3code 的方案是将新 Bundle 推送到/sdcard/Download/t3code-hotupdate/修改 App 的AssetManager使其优先从/sdcard/Download/t3code-hotupdate/加载main.jsbundle需 App 代码配合t3code 提供 patch 脚本这种“运行时重定向”方案已在 3 个 RN 项目中验证可行。4.6 问题复现与最终验证再次操作商品详情页日志变为[DEBUG] ImageLoader: start loading https://cdn.xxx.com/item/123456.jpg [INFO] ImageLoader: loaded in 1240ms [INFO] ImageLoader: cache hit for https://cdn.xxx.com/item/123456.jpg确认问题修复。最后导出本次调试的完整证据# 导出日志、沙盒快照、包体报告 t3code log --since 10m --export zip --output debug-session-20240520.zip t3code sandbox export --path Documents/ --filter *.log --output logs.zip t3code bundle report ecommerce-2.3.0.ipa --output report.html将debug-session-20240520.zip发给 QA 同事他只需双击解压打开report.html就能看到