企业官网建设流程全解析

1. 项目概述：这不是一个“WorkBuddy 教程”，而是一份上线级 App 的实战手记

你搜“WorkBuddy”时，看到的大多是零散的安装截图、模糊的界面动图，或是夹杂着“国际版”“官网68s.cc”这类可疑链接的推广帖——但没人告诉你：WorkBuddy 本身不是开发工具，它是一个面向低代码协作场景的轻量级任务协同平台，其核心价值在于“规则驱动的任务流编排”，而非替代 React Native 或 Flutter 的 App 构建器。这一点，是踩过十六个坑之后才真正想明白的起点。

我用 WorkBuddy 搭建的这个 App，最终上线了 iOS App Store 和华为应用市场（未上架 Google Play），主体功能是“一线工程师现场巡检工单闭环系统”：扫码触发检查项 → 拍照上传 → 自动校验合规性 → 推送审批 → 同步 ERP 工单状态。整个过程不依赖原生开发，全部通过 WorkBuddy 的 Web App 封装 + 原生壳体（WebView 容器）+ 平台合规适配完成。它不是“玩具 Demo”，而是已在三个省会城市电力公司稳定运行 11 个月的真实生产系统。

为什么强调“能上线”？因为绝大多数 WorkBuddy 项目卡在“本地能跑”就结束了——但上线不是加个图标、填个描述那么简单。它意味着你要直面苹果审核的 4.3 条款（重复功能）、华为的 SDK 合规扫描、安卓各厂商的启动白屏检测、HTTPS 证书链完整性、iOS 的 ATS 强制要求、Web View 中 JSBridge 的安全沙箱隔离……这些 WorkBuddy 官方文档里不会写，社区帖子里也极少提。而这十六个坑，每一个都来自真实审核驳回记录、真机日志抓取、平台后台警告截图。

适合谁看？如果你正面临这些情况：

• 公司要求两周内交付一个带扫码、拍照、审批流的内部工具 App，但没有专职 iOS/Android 开发；
• 你已用 WorkBuddy 搭出 Web 版，但被老板问“能不能装到手机里”；
• 你试过 Cordova 或 Capacitor 封装，却在 iOS 17 上遇到 WKWebView 的window.crypto.subtle不可用问题；
• 你下载了所谓“WorkBuddy 国际版 APK”，结果发现是套壳广告聚合页。

那么这篇内容就是为你写的。它不教你怎么点按钮生成页面，而是告诉你：当 WorkBuddy 的输出遇上真实应用商店的铁门，你该备哪把钥匙、敲哪块砖、绕哪段墙。

2. 六个阶段拆解：从“能用”到“能过审”的不可跳过路径

2.1 阶段一：明确边界——WorkBuddy 能做什么，不能做什么

很多团队失败的第一步，是误把 WorkBuddy 当成“App Maker”。它本质是一个基于 YAML 规则定义的前端逻辑引擎，运行在 WebView 环境中。它的能力象限非常清晰：

提示：WorkBuddy 的skill机制（如workbuddy skill）本质是预置的 JS 函数集合，不是插件生态。所谓“MCP Skill”或“OPC 考试 Skill”，只是封装了特定行业 API 的调用逻辑，不改变底层能力边界。

我最初做的“毒辣剪辑 App”原型（注意：此处指内部视频质检工具，非网络热词所指）就栽在这里——试图用 WorkBuddy 直接调用 FFmpeg.wasm 处理 4K 视频，结果在 iPad 上内存溢出崩溃。后来改用 WorkBuddy 仅做任务调度，视频上传交由原生模块分片处理，问题迎刃而解。

2.2 阶段二：架构选型——为什么放弃 Capacitor，选择自研 WebView 容器

社区主流方案是 Capacitor + WorkBuddy Web 输出。但我们在华为应用市场初审就被拒三次，原因全是“未声明使用第三方 SDK”。Capacitor 默认集成@capacitor/core、@capacitor/android、@capacitor/ios，每个包都包含大量未使用的桥接方法（如CameraPlugin的getPhoto方法在我们项目中从未调用），而华为扫描工具会将所有引用的类名计入 SDK 清单。

我们最终采用自研轻量 WebView 容器，核心逻辑只有三部分：

1. 启动器层：Android 用WebViewAssetLoader加载 assets/www，iOS 用WKWebView+NSBundle.main.path(forResource:)；
2. 桥接层：仅实现 4 个必要接口：takePhoto()、uploadFile()、showToast()、openUrl()；
3. 安全层：强制 HTTPS 加载远程资源，禁用javascriptEnabled = false以外的所有危险选项（如allowContentAccess = false）。

这样做体积减少 62%（Capacitor 包体 12.4MB → 自研容器 4.7MB），且可精确控制每个 API 的权限声明。例如 AndroidManifest.xml 中只声明：

<uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" />

而 Capacitor 会默认添加ACCESS_FINE_LOCATION、RECORD_AUDIO等无关权限，触发华为“权限滥用”警告。

2.3 阶段三：合规改造——让 WorkBuddy Web 输出符合 App Store 审核条款

WorkBuddy 默认输出的 HTML 是为桌面浏览器优化的，直接封装会触发 iOS 审核的三大雷区：

雷区一：无原生导航栏（4.3 条款）
App Store 要求“用户能清晰识别当前层级”。WorkBuddy 的单页路由（#page1）在 WKWebView 中无法触发系统返回手势。解决方案：在index.html中注入原生导航监听：

// iOS 侧注入的 JS window.webkit.messageHandlers.navHandler.postMessage({ action: 'push', title: '巡检任务', canGoBack: true });

Android 侧用addJavascriptInterface实现同等逻辑。WorkBuddy 页面顶部留出 44px 安全区，由原生层渲染导航栏。

雷区二：缺少离线能力（2.4.5 条款）
苹果要求“核心功能在无网络时仍可基础使用”。WorkBuddy 的 IndexedDB 缓存默认只存表单数据，不存页面模板。我们修改了workbuddy-runtime.js，在onload时预加载所有.yaml页面定义到localStorage，并重写fetchPage()方法：

function fetchPage(pageId) { const cached = localStorage.getItem(`page_${pageId}`); if (cached && navigator.onLine === false) return Promise.resolve(JSON.parse(cached)); return fetch(`/pages/${pageId}.yaml`).then(r => r.text()).then(text => { localStorage.setItem(`page_${pageId}`, text); return YAML.parse(text); }); }

雷区三：隐私政策缺失（5.1.1 条款）
WorkBuddy 默认不收集用户数据，但 WebView 容器会记录User-Agent、screen.width等设备信息。我们增加隐私弹窗（首次启动强制展示），内容严格按 GDPR 和中国《个人信息保护法》双标准撰写，并提供“拒绝追踪”按钮——点击后清空所有 IndexedDB 数据并禁用navigator.sendBeacon()。

2.4 阶段四：性能攻坚——解决 iOS 17 下 WKWebView 的 JS 执行瓶颈

iOS 17 对 WKWebView 的setTimeout和Promise.then做了更严格的队列限制，导致 WorkBuddy 的表单校验逻辑（大量同步循环）出现 300ms+ 延迟。实测发现：当页面含超过 12 个动态校验规则时，输入框失焦响应超时，触发苹果“App 无响应”判定。

根本解法不是优化 JS，而是重构执行模型：

• 将校验逻辑从onBlur改为onInput的节流触发（lodash.throttle(func, 300)）；
• 关键校验（如身份证号格式）移至 Web Worker，避免阻塞主线程；
• 对YAML.parse()结果做 Memoize 缓存，相同页面 ID 的解析结果复用；
• 禁用 WorkBuddy 默认的console.log输出（iOS 会同步写入系统日志，拖慢渲染）。

最有效的改动是启用 WKWebView 的allowsInlineMediaPlayback = true，这使视频预览帧率从 12fps 提升至 24fps，大幅降低用户感知卡顿。

2.5 阶段五：发布适配——应对各安卓渠道的差异化要求

华为、小米、vivo 的审核规则差异极大：

• 华为：要求targetSdkVersion=33，且必须使用 HMS Core 推送（不能用 Firebase）；
• 小米：强制要求android:exported="true"的 Activity 必须有<intent-filter>；
• vivo：扫描到WebView.getSettings().setJavaScriptEnabled(true)会要求提供《JS 安全评估报告》。

我们的应对策略是：

1. 构建多渠道版本，用 Gradle Flavor 分离配置：

flavorDimensions "channel" productFlavors { huawei { dimension "channel" } xiaomi { dimension "channel" } vivo { dimension "channel" } }

2. 华为版集成hms-push，推送消息走HmsMessaging.getInstance(this).getToken()；
3. 小米版在AndroidManifest.xml中为启动 Activity 显式添加：

<intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter>

4. vivo 版将 JS 启用逻辑改为运行时判断：

if (Build.MANUFACTURER.equalsIgnoreCase("vivo")) { webView.getSettings().setJavaScriptEnabled(false); // 通过原生桥接调用 JS } else { webView.getSettings().setJavaScriptEnabled(true); }

2.6 阶段六：上线后运维——建立可持续的更新与监控体系

App 上线不是终点，而是运维起点。WorkBuddy 的 Web 内容更新必须与原生壳体解耦：

• 所有页面 YAML、静态资源（CSS/JS/图片）托管在私有 CDN，URL 带版本哈希（/v2.3.1/pages/login.yaml）；
• 原生层启动时请求https://cdn.example.com/version.json获取当前 Web 版本号，若本地缓存版本旧于 CDN，则静默下载新包；
• 错误监控接入 Sentry，但过滤掉 WorkBuddy 的YAML parse error（这是业务配置错误，非代码缺陷），只上报WebView crashed、Network timeout、Storage quota exceeded三类致命错误；
• 用户反馈通道：长按底部导航栏 3 秒触发“问题上报”，自动截取当前 WebView 快照 + 控制台日志 + 设备型号，加密上传至内部工单系统。

这套机制让我们实现了 98.7% 的 Web 更新无需发版，平均热更新耗时 2.3 秒（从用户点击“检查更新”到新页面加载完成）。

3. 十六个坑详解：每个都附带真实日志与修复代码

3.1 坑一：iOS 审核被拒“4.3 - Duplicate Functionality”，因首页含“联系我们”跳转外链

现象：App Store Connect 显示 “Your app simply duplicates the content and functionality of existing apps on the App Store.”
根因：WorkBuddy 默认首页的“客服电话”按钮调用window.open('tel:+8613800138000')，苹果认为这是“复制电话 App 功能”。
修复：改用原生桥接：

// WorkBuddy 页面中 document.getElementById('contact-btn').onclick = () => { window.webkit.messageHandlers.callHandler.postMessage({ number: '+8613800138000' }); };

iOS 原生层：

func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) { if message.name == "callHandler", let body = message.body as? [String: String] { if let number = body["number"] { guard let url = URL(string: "tel://\(number)") else { return } UIApplication.shared.open(url) } } }

3.2 坑二：华为审核提示“未声明使用 com.huawei.hms.push”，但实际未集成 HMS

现象：华为应用市场后台扫描报告列出com.huawei.hms.push.HmsInstanceId类名，要求补充 HMS 声明。
根因：Capacitor 的@capacitor/android包含对 HMS 的反射调用（兼容性代码），即使未启用也会被扫描到。
修复：在build.gradle中排除 HMS 相关依赖：

implementation(project(':capacitor-android')) { exclude group: 'com.huawei.hms', module: 'push' exclude group: 'com.huawei.hms', module: 'base' }

3.3 坑三：小米手机启动白屏超 5 秒，触发 ANR

现象：小米 13 启动 App 后黑屏 6.2 秒，Logcat 显示I/ActivityThread: handleLaunchActivity耗时异常。
根因：WorkBuddy 的index.html引入了workbuddy-runtime.js（2.1MB），小米 WebView 初始化时解析 JS 超时。
修复：拆分 JS 文件，首屏只加载核心 runtime（<200KB），其余按需动态 import：

<!-- index.html --> <script src="/js/core-runtime.min.js"></script> <script> // 首屏渲染完成后加载完整 runtime setTimeout(() => { import('/js/full-runtime.min.js'); }, 1000); </script>

3.4 坑四：vivo X90 拍照后图片旋转 90 度

现象：用户用后置摄像头拍照，图片在 App 内显示逆时针旋转 90°。
根因：vivo 系统相机返回的 JPEG 包含 EXIF Orientation 标签（值为 6），但 WorkBuddy 的img标签不解析 EXIF。
修复：在拍照回调中用exifr库修正：

async function fixOrientation(file) { const arrayBuffer = await file.arrayBuffer(); const exif = await exifr.parse(arrayBuffer); if (exif?.Orientation === 6) { const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d'); const img = new Image(); img.src = URL.createObjectURL(file); await img.decode(); canvas.width = img.height; canvas.height = img.width; ctx.translate(canvas.width/2, canvas.height/2); ctx.rotate(90 * Math.PI / 180); ctx.drawImage(img, -img.width/2, -img.height/2); return new Blob([canvas.toBlob()], {type: 'image/jpeg'}); } return file; }

3.5 坑五：iOS 17.4 下window.crypto.subtle.digest()报错

现象：在 iOS 17.4 Beta 版本中，WorkBuddy 的登录密码 SHA256 加密失败，控制台报TypeError: undefined is not an object (evaluating 'window.crypto.subtle.digest')。
根因：WKWebView 在某些 Beta 版本中禁用了crypto.subtle，需降级到crypto-js。
修复：动态检测并 fallback：

function hashPassword(password) { if (window.crypto && window.crypto.subtle) { return window.crypto.subtle.digest('SHA-256', new TextEncoder().encode(password)); } else { return CryptoJS.SHA256(password).toString(CryptoJS.enc.Hex); } }

3.6 坑六：华为应用市场扫描出“高危权限 READ_PHONE_STATE”

现象：华为后台提示 “您的应用申请了高危权限 READ_PHONE_STATE，但未在隐私政策中说明用途”。
根因：WorkBuddy 的workbuddy-runtime.js包含navigator.userAgent采集逻辑，部分 Android WebView 实现会触发READ_PHONE_STATE权限检查。
修复：重写 UA 采集，避开系统 API：

// 替换 navigator.userAgent 为安全版本 const safeUA = `WorkBuddyApp/${APP_VERSION} (${deviceInfo()})`; function deviceInfo() { return `${navigator.platform}; ${navigator.language}`; }

3.7 坑七：App Store 审核被拒“2.3.10 - Unresponsive UI”，因表单校验阻塞主线程

现象：审核员操作“输入身份证号”后等待 3 秒无响应，截图显示光标静止。
根因：WorkBuddy 的idCardValidator使用正则^[\d]{17}[\d|x|X]$，在长文本输入时频繁执行，iOS WebKit 优化不足。
修复：改用 Web Worker 校验：

// main.js const worker = new Worker('/js/id-validator.worker.js'); worker.postMessage(idNumber); worker.onmessage = (e) => { if (e.data.valid) showSuccess(); };

// id-validator.worker.js self.onmessage = (e) => { const valid = /^[1-9]\d{5}(18|19|([23]\d))\d{2}((0[1-9])|(10|11|12))(([0-2][1-9])|10|20|30|31)\d{3}[0-9Xx]$/.test(e.data); self.postMessage({ valid }); };

3.8 坑八：小米应用商店提示“未适配 MIUI 14”，因未设置android:resizeableActivity

现象：小米商店审核不通过，提示 “请适配 MIUI 14 分屏模式”。
根因：MIUI 14 要求android:resizeableActivity="true"，但 WorkBuddy 的 WebView 在分屏下布局错乱。
修复：在AndroidManifest.xml中为 Activity 设置：

<activity android:name=".MainActivity" android:resizeableActivity="false" android:supportsPictureInPicture="false" android:configChanges="orientation|screenSize|smallestScreenSize" />

并在onConfigurationChanged()中强制重置 WebView 尺寸。

3.9 坑九：iOS 16.6 下WKWebView的window.history.pushState失效

现象：页面跳转后 URL 不变，返回按钮失效。
根因：iOS 16.6 修复了pushState的跨域 bug，但 WorkBuddy 的路由依赖hashchange事件。
修复：监听popstate事件并手动触发hashchange：

window.addEventListener('popstate', (e) => { const hash = location.hash || '#home'; window.dispatchEvent(new HashChangeEvent('hashchange', { oldURL: '', newURL: hash })); });

3.10 坑十：vivo 应用商店扫描出“WebView JavaScriptEnabled 高危风险”

现象：vivo 后台要求提供《JS 安全评估报告》，否则下架。
根因：vivo 将setJavaScriptEnabled(true)列为高危行为，需证明 JS 执行环境受控。
修复：在WebViewClient中重写shouldOverrideUrlLoading，禁止任何非白名单 URL：

@Override public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) { String url = request.getUrl().toString(); if (url.startsWith("https://your-cdn-domain.com/") || url.startsWith("file:///android_asset/")) { return false; // 允许加载 } return true; // 阻止加载 }

3.11 坑十一：华为 HMS 推送收不到消息，因未配置agconnect-services.json

现象：华为版 App 无法接收推送，Logcat 显示HMS SDK init failed。
根因：agconnect-services.json文件未放入app/src/main目录，或build.gradle中未应用 HMS 插件。
修复：

1. 将agconnect-services.json放入app/src/main；
2. 在app/build.gradle添加：

apply plugin: 'com.huawei.agconnect' dependencies { implementation 'com.huawei.hms:push:6.13.0.300' }

3.12 坑十二：iOS 审核被拒“5.1.1 - Privacy - Data Collection and Storage”，因 IndexedDB 存储用户手机号

现象：苹果要求说明 “Why are you collecting phone numbers?”，并提供数据删除入口。
根因：WorkBuddy 的表单自动保存功能将手机号存入 IndexedDB，但未提供清除入口。
修复：在设置页添加“清除本地数据”按钮，执行：

indexedDB.deleteDatabase('workbuddy-db'); localStorage.clear(); sessionStorage.clear();

3.13 坑十三：小米手机 WebView 渲染文字模糊，因未启用硬件加速

现象：小米 12 上文字边缘锯齿明显，尤其小字号。
根因：小米 WebView 默认关闭硬件加速。
修复：在Application类中启用：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { WebView.setWebContentsDebuggingEnabled(true); // 强制硬件加速 getWindow().setFlags(WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED); }

3.14 坑十四：vivo X Fold+ 折叠屏下 WebView 宽度计算错误

现象：展开状态下页面宽度只有屏幕一半。
根因：vivo 折叠屏 WebView 的window.innerWidth返回折叠态宽度。
修复：用screen.width替代：

const width = window.screen.width; document.documentElement.style.fontSize = `${width / 375 * 100}px`;

3.15 坑十五：App Store 审核被拒“4.0 - Design”，因启动图与首页 UI 颜色不一致

现象：苹果指出 “Launch Screen does not match the first screen of your app”。
根因：WorkBuddy 的首页背景色是#f8f9fa，但启动图 PNG 是纯白#ffffff。
修复：生成启动图时，用 Sketch 导出#f8f9fa背景的 PNG，并在LaunchScreen.storyboard中设置：

<view key="view" clipsSubviews="YES" contentMode="scaleToFill" backgroundColor="f8f9fa">

3.16 坑十六：华为应用市场提示“未声明使用 android.permission.POST_NOTIFICATIONS”，但 targetSdkVersion=33

现象：华为后台扫描到NotificationManagerCompat类，要求声明通知权限。
根因：WorkBuddy 的showToast()方法在 Android 13+ 需要POST_NOTIFICATIONS权限。
修复：在AndroidManifest.xml中声明：

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

并在首次调用showToast()前动态申请：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { if (ContextCompat.checkSelfPermission(this, Manifest.permission.POST_NOTIFICATIONS) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.POST_NOTIFICATIONS}, 100); } }

4. 可复用经验：一套能落地的 WorkBuddy App 工程化模板

4.1 目录结构标准化：让团队协作不踩坑

我们固化了一套目录结构，所有新项目必须遵循：

workbuddy-app/ ├── web/ # WorkBuddy 项目源码（YAML+JS+CSS） │ ├── pages/ # 页面定义（login.yaml, task-list.yaml） │ ├── assets/ # 静态资源（images/, fonts/, icons/） │ └── js/ # 自定义逻辑（id-validator.js, upload-handler.js） ├── native/ # 原生壳体代码 │ ├── android/ # Android Studio 项目 │ └── ios/ # Xcode 项目 ├── cdn/ # 构建后上传至 CDN 的产物 │ ├── v1.0.0/ # 版本化目录 │ └── version.json # 当前最新版本映射 ├── scripts/ # 自动化脚本 │ ├── build-web.sh # 构建 Web 产物并上传 CDN │ ├── build-android.sh # 构建多渠道 APK │ └── build-ios.sh # 构建 IPA 并上传 TestFlight └── docs/ # 合规文档（隐私政策、权限说明、SDK 清单）

关键约束：

• web/目录禁止出现node_modules，所有依赖通过 CDN 引入；
• native/目录中AndroidManifest.xml和Info.plist必须用sed命令动态注入渠道标识；
• cdn/目录由 CI 自动管理，人工禁止直接修改。

4.2 WorkBuddy 配置最佳实践：规避 80% 的运行时错误

YAML 页面规范

• 所有input组件必须设置required: true/false，避免空值提交；
• select组件的options必须用数组字面量，禁用函数调用：

# ✅ 正确 options: - value: "1" label: "高压设备" - value: "2" label: "低压设备" # ❌ 错误（WorkBuddy 不支持） options: "{{ getEquipmentTypes() }}"

JS 扩展规范

• 禁止在onLoad中执行耗时操作（如fetch），改用onReady；
• 所有异步操作必须try/catch，错误统一上报window.onerror；
• 自定义函数命名必须带前缀wb_，避免与 WorkBuddy 内置方法冲突：

// ✅ window.wb_uploadPhoto = async (file) => { ... }; // ❌ window.uploadPhoto = async (file) => { ... };

4.3 审核材料清单：一次准备，永久复用

每次提交前，我们生成标准化审核包，包含：

• privacy-policy.html：双语（中英），明确列出收集字段（仅device_id,network_type,screen_size）、用途（“用于故障诊断”）、保留期限（“30 天后自动删除”）；
• permissions-explained.md：逐条解释每个权限的必要性，例如：

  CAMERA：用于现场巡检拍照，无此权限无法执行核心任务，用户可在系统设置中随时关闭；

• sdk-inventory.json：JSON 格式列出所有第三方代码，格式为：

{ "name": "WorkBuddy Runtime", "version": "2.8.1", "license": "MIT", "url": "https://workbuddy.dev/runtime" }

• screenshots.zip：按平台要求尺寸生成截图（iOS 6.5 英寸、华为 1080x2340），每张图右下角添加半透明水印 “v2.3.1 - TEST ONLY”；

4.4 监控告警阈值：用数据驱动运维

我们设置了 5 个核心监控指标，超标自动创建 Jira 工单：

这套机制让我们将平均故障恢复时间（MTTR）从 47 分钟降至 8.3 分钟。

5. 实操心得：那些文档不会写的细节

5.1 关于“WorkBuddy 国际版”的真相

搜索“workbuddy 国际版”会出现大量带68s.cc的链接，这些是第三方聚合站，与 WorkBuddy 官方无关。真正的国际版指 WorkBuddy Cloud 的多语言支持（en-US、zh-CN、ja-JP），需在settings.yaml中配置：

i18n: default: "zh-CN" locales: - "en-US" - "ja-JP"

然后在页面中用{{ t('login.title') }}调用翻译。所谓“国际版 APK”都是套壳应用，内嵌广告页，切勿下载。

5.2 “CodeBuddy 和 WorkBuddy”的关系

CodeBuddy 是 WorkBuddy 团队推出的 VS Code 插件，用于本地编辑 YAML 页面并实时预览，与 App 开发无直接关系。它不参与构建流程，仅提升开发效率。混淆二者会导致团队在错误方向投入精力。

5.3 安卓应用平台上线的关键卡点

• 华为：必须通过“华为开发者联盟”实名认证（企业营业执照），个人开发者无法上架；
• 小米：需额外签署《小米应用商店开发者协议》，并缴纳 1000 元保证金；
• vivo：要求提供《软件著作权登记证书》，无证项目直接拒审；
• OPPO：强制要求接入 OPPO Push SDK，且推送文案需经 OPPO 内容审核。

5.4 WorkBuddy 的字体设置技巧

WorkBuddy 默认使用系统字体，但在 iOS 上中文显示偏细。我们在web/assets/css/custom.css中覆盖：

body { font-family: -apple-system, BlinkMacSystemFont, "PingFang SC", "Helvetica Neue", sans-serif; } /* 针对 iOS 加粗中文 */ @media screen and (-webkit-min-device-pixel-ratio: 2) { body { -webkit-font-smoothing: antialiased; text-rendering: optimizeLegibility; } }

5.5 最后一条心得：永远先做“最小可行上线版”

不要试图一次性满足所有平台要求。我们的策略是：

1. 第一周：只做 iOS 版，过审后立即上线；
2. 第二周：基于 iOS 版代码，快速适配华为；
3. 第三周：针对小米、vivo 的特殊要求打补丁；
4. 第四周：统一更新 Web