移动端 App 开发方法论清单（完善版）
零、移动端特有的信任边界推导
先把移动端和后端系统的关键差异摆出来：客户端代码、本地存储、设备环境全部处于用户手中，理论上都可能被篡改、被抓包、被逆向。信任边界的起点不是"用户会不会输入恶意数据"，而是"用户手里的这个 App 本身还能不能被信任"。
检查项：
[ ] 是否已明确哪些"客户端计算/判断"结果是不可信的，必须在服务端二次校验（尤其是价格、权限、库存类）
[ ] 是否已经识别出所有存储在设备本地的敏感数据，并评估过是否需要加密存储
[ ] 是否已针对自己App的实际业务，重新走一遍"输入→信任→行动"的推导，而不是直接套用这张表
零之一、服务端侧的移动端专项防护（新增）
信任边界推导的落点不能只停在"客户端不可信"这句结论上——它必须转化为服务端的具体防御动作，否则就是一句正确的空话。
[ ] 是否对同一账号的多设备并发登录、Token 复用有明确策略（允许几台设备同时在线、是否踢出旧设备）
[ ] 关键接口是否有基于设备/账号维度的限流与异常调用检测，而不是只靠 HTTPS 和登录态兜底
[ ] 服务端下发的功能开关（Feature Flag / 远程配置）本身是否有误操作保护（比如全量关闭核心功能前的二次确认、变更审计日志），因为它是"止损路径"里权限最大的一环，一旦被误用影响面等同于一次全量故障
[ ] 越权访问（水平越权/垂直越权）是否针对移动端高频接口（如订单、余额、个人信息）做过专项测试，而不是只做过常规的登录鉴权测试
一、可观测性（移动端视角）
移动端的可观测性比后端更难，原因很简单：问题发生在你看不到的设备上，没有服务器日志可以直接查看。
1.1 崩溃与异常监控
[ ] 是否接入了崩溃收集（Crashlytics / Bugly / Sentry 等），崩溃率是否有仪表盘可视化，而不是等应用商店评分掉了才发现
[ ] 非崩溃类异常（ANR、卡顿、白屏、接口超时）是否也被监控，而不是只关注硬崩溃
[ ] 崩溃日志中是否包含足够的上下文（用户ID/设备型号/系统版本/App版本/关键操作路径），而不是只有一条堆栈
[ ] 崩溃率、异常率是否设置了告警阈值并有人实际响应，而不是仪表盘建了但没人看（"接入监控"和"监控在起作用"是两回事）
1.2 用户行为与业务埋点
[ ] 关键业务路径（注册、下单、支付、核心功能使用）是否有埋点，能还原用户实际操作路径，而不是只能看到"这个接口被调用了"
[ ] 埋点数据是否和崩溃/异常数据能关联起来查看（同一用户在崩溃前做了什么）
1.3 客户端性能监控
[ ] 启动耗时、页面加载耗时、接口响应耗时是否有分位数（P50/P95）监控，而不是只看平均值
[ ] 内存占用与内存泄漏、电量消耗是否纳入监控范围，而不是纯靠人工体感反馈
[ ] 包体积增长是否有持续跟踪（每次发版对比），而不是等用户抱怨"App 越来越大"才回头排查
1.4 多版本并存下的可观测性
[ ] 监控数据是否可以按App版本号、系统版本、设备型号维度拆分查看（否则"整体崩溃率正常"可能掩盖了"某一机型崩溃率极高"）
二、设备与系统碎片化适配
这是移动端独有、后端系统完全不需要考虑的一类风险：同一份代码要在成千上万种硬件+系统版本组合上运行。
[ ] 是否明确了最低支持的系统版本（iOS/Android），以及这个决定背后的依据（用户分布数据？还是拍脑袋）
[ ] 是否在有代表性的低端机型/旧系统版本上做过实测，而不是只在开发者自己的旗舰测试机上验证
[ ] 屏幕适配（不同分辨率、刘海屏/挖孔屏、折叠屏）是否有统一方案，而不是逐个页面临时处理
[ ] 系统级差异（如Android各厂商定制ROM对后台进程、推送、权限的限制）是否有针对性处理方案
[ ] 深色模式 / 系统主题适配是否纳入设计规范并全局落实，而不是只做了主流程页面、遗漏了弹窗、第三方 SDK 页面等边角场景
[ ] 动态字体大小、系统级显示缩放是否做过适配验证，避免用户调大字号后出现文字截断、布局错位
三、网络韧性与离线体验
移动端用户所处的网络环境完全不可控——电梯里、地铁上、弱WiFi下都要考虑。
[ ] 弱网/断网场景下，App的表现是"明确的失败提示+重试"，还是无提示地卡死或白屏
[ ] 是否规划了离线可用的能力范围（哪些功能必须联网，哪些可以离线使用本地缓存），而不是默认所有功能都强依赖实时网络
[ ] 本地缓存数据与服务端数据的一致性策略是否明确（缓存多久过期、冲突时以谁为准）
[ ] 弱网下的请求超时、重试、退避策略是否统一管理，而不是每个接口各写各的
[ ] 当服务端下发的远程配置/数据获取失败时，客户端是否有本地兜底默认值，而不是直接崩溃或功能整体不可用（这一点和"发布后无法立即撤回"直接相关：一旦下发配置出错，能兜住的只有客户端自身的容错设计）
四、权限与隐私合规
[ ] App申请的每一项系统权限，是否都能对应到一个具体功能，且申请时机是"用到时申请"而不是"启动即申请"
[ ] 隐私政策中声明的数据收集范围，是否与App实际行为（包括接入的第三方SDK的行为）一致
[ ] 是否识别过目标上架地区/用户群体对应的隐私法规要求（如涉及未成年人数据、欧盟用户的GDPR等），而不是用一套默认方案覆盖所有地区
[ ] 用户数据的可删除性/可导出性（账号注销后数据是否真正清除）是否有明确实现，而不是只在协议里承诺
[ ] 无障碍能力（VoiceOver/TalkBack 支持、颜色对比度、可点击区域大小）是否纳入需求范畴——这既是部分地区的强制合规要求，也是"最坏情况"思维方式本该覆盖的一类用户群体，而不是被默认排除在测试范围之外
五、客户端安全
[ ] 本地存储中的敏感数据（Token、密钥、用户隐私字段）是否使用了系统级安全存储（Keychain / Android Keystore），而不是明文存放
[ ] 是否对关键接口做了基本的防抓包/防重放考虑（如证书锁定 Certificate Pinning、请求签名），还是完全依赖HTTPS默认防护
[ ] 是否评估过被逆向/反编译后的风险敞口（核心业务逻辑是否过度依赖客户端、是否有基础的代码混淆），而不是假设没人会去反编译
[ ] Root/越狱设备、模拟器等异常运行环境，是否需要识别并采取相应策略（视业务敏感度决定，不是所有App都需要）
五之一、第三方 SDK 供应链治理（新增，从原第零节拆分细化）
第零节已经指出"SDK 可能越权采集数据"，但这只是供应链风险的其中一种，实际上至少有三类不同性质的风险需要分开管理：
[ ] SDK 数据采集范围是否越出隐私声明（数据合规风险）
[ ] 是否对接入的 SDK 做过来源审计，评估是否存在被劫持、被污染、或本身包含恶意代码的供应链风险，而不是"能用就接"
[ ] 多个 SDK 之间是否存在版本冲突或符号冲突，是否有统一的依赖版本管理机制，而不是各业务线各自引入互不通气
[ ] SDK 升级是否有独立的兼容性验证流程（尤其是广告、支付、推送这类高频更新的 SDK），避免第三方无预警升级后引发线上问题却难以定位根因
六、应用商店合规与发布策略
后端系统发版你自己说了算；移动端发版要过应用商店这一关，且发布后无法立即撤回到所有用户手机上。
[ ] 是否清楚目标应用商店（App Store / 各安卓渠道）的审核规则，避免功能设计阶段就踩中大概率被拒的红线（如支付方式、隐私合规、诱导分享等）
[ ] 是否有灰度发布机制（应用商店分阶段发布、内测渠道），而不是每次都直接全量推送给所有用户
[ ] 是否有强制更新/版本兼容策略，应对"服务端API已升级但仍有用户停留在旧版本App"的情况，而不是任由旧版本裸奔报错
[ ] 紧急问题的止损路径是否明确：由于应用商店审核有周期，出现严重问题时能否通过服务端开关快速降级某个功能，而不是只能等新版本审核通过
[ ] 多渠道打包（不同安卓应用市场、不同定制需求版本）的构建与发布流程是否自动化，而不是人工逐个操作容易出错
[ ] 若使用了热更新/动态化方案（如 React Native、Flutter 的 OTA 更新、插件化框架），是否清楚其相对应用商店审核规则的合规边界（尤其 iOS 对"绕过审核动态下发可执行代码"的限制），而不是先上线再赌不会被下架
[ ] 是否有 Feature Flag / A/B 测试机制支撑灰度发布落地，而不是"灰度发布"停留在应用商店分阶段推送这一层，无法对单个功能做独立的开关和实验
七、跨端一致性（如涉及 iOS / Android / 小程序 / H5 多端）
[ ] 同一业务功能在不同端上的行为、文案、边界条件处理是否保持一致，是否有统一的产品/技术规范文档，而不是各端各自解读需求
[ ] 核心业务逻辑（尤其是计价、权限判断类）是否尽量收敛到服务端统一实现，避免多端各自实现产生不一致
[ ] 多端团队并行开发时，接口变更是否有统一的通知机制，避免某一端因为不知情而线上出错
[ ] 国际化与本地化（多语言文案动态加载、RTL 布局镜像、时区/货币/度量单位换算）是否在多端有统一方案，而不是出海时才发现某一端完全没考虑过这些维度
八、前后端协作与接口规范
前面几节都在讲"系统内部会不会出问题"，这一节讲一个更容易被忽视的地方：前端和后端本质上是两个团队/两份代码库，靠"接口"这个脆弱的界面维系一致性。这里的风险源头不是恶意输入，而是"沟通没有对齐"——同样会导致线上事故，只是根源在人而不在代码。
8.1 接口契约管理
[ ] API文档是否是前后端共同认可的"唯一真相来源"，还是后端口头说一套、文档写另一套、前端猜第三套
[ ] 接口文档是否随代码变更同步更新，还是等联调出问题了才回头补文档（推荐用OpenAPI等可校验的契约格式，而非纯Wiki手写、容易和实现脱节）
[ ] 字段的可选性、默认值、枚举范围是否明确定义，而不是靠前后端各自猜测"这个字段是不是一定有值"
[ ] 接口的Breaking Change（字段删除、类型变更、语义变更）是否有版本兼容策略（新老接口并存过渡期），而不是要求前后端代码必须同一天同时上线
8.2 Mock数据与联调
[ ] 前端在后端接口未就绪前，是否有基于接口文档生成的Mock数据支持独立开发，而不是被迫等后端联调完才能开始
[ ] Mock数据的结构是否和真实接口保持严格一致（字段、类型、异常状态都覆盖），否则"Mock测试通过"和"联调后炸"是两码事
8.3 错误码与异常处理规范
[ ] 是否有统一的错误码/错误信息规范，前后端对"这个错误该怎么展示给用户"有一致理解，而不是后端返回500、前端不知道该提示什么
[ ] 业务错误（如库存不足）和系统错误（如服务不可用）是否在错误码层面明确区分，前端才能决定是提示用户重试还是提示联系客服
[ ] 是否统一了错误响应的结构（如统一的 code/message/data 包裹），而不是有的接口直接返回数据、有的又包一层，前端要为每个接口写不同的解析逻辑
8.4 鉴权与会话职责划分
[ ] Token的获取、刷新、过期处理逻辑是否前后端有明确约定（谁来触发刷新、刷新失败前端该如何处理），而不是前端自己摸索着写
[ ] 权限判断是否明确"服务端为准、客户端展示为辅"——这一点在第零节的信任边界推导里已经提到，这里从协作角度再强调一次：前端做的任何权限相关的UI隐藏/禁用，后端必须有对应的服务端校验，不能把它当成唯一防线
8.5 协作流程
[ ] 接口设计是先由后端出方案、还是前后端共同评审，是否有明确的流程，而不是"谁先写谁说了算"
[ ] 接口变更（哪怕只是新增一个可选字段）是否有通知机制触达所有依赖方，而不是改了但没人知道，等到某个页面线上出错才发现
[ ] 前后端是否有共享的测试环境和数据，还是经常出现"我这边好的，你那边环境数据不一样所以复现不了"的扯皮
九、测试策略的工具化落地（新增）
前面各节都在讲"该测什么"，这一节单独把"用什么机制让测试真正被执行"提出来——原清单里"实测""灰度"这些动作缺少可执行的工具层支撑，容易停留在原则层面。
[ ] 是否有自动化 UI 测试覆盖核心业务路径，而不是每次发版都靠人工点一遍所有页面
[ ] 是否使用真机云测试平台（覆盖多机型/多系统版本）作为发版前的标准环节，而不是仅依赖团队内部有限的几台测试机
[ ] 是否有独立于研发的移动端 QA 角色或职责分工；如果团队规模小、没有专职移动端 QA，是否明确了由谁兜底这份清单里的检查项，而不是默认"大家应该都做了"
[ ] 是否有独立的发布工程角色/职责，负责多渠道打包、灰度节奏、审核进度跟踪，而不是把这些临时分摊给随便哪个研发
十、推送通道治理（新增）
第零节把"推送内容被伪造"列为安全风险，但推送本身还有一类与安全无关、却极其现实的移动端专属问题——到达率。
[ ] 是否清楚目标市场的推送生态碎片化情况（尤其安卓各厂商私有推送通道），并有对应的多通道兜底策略，而不是只接了一套标准方案就默认所有设备都能收到
[ ] 推送到达率、点击率是否有监控，而不是"推了就算发出去了"
[ ] 锁屏可见的推送内容是否做过隐私脱敏审查（如订单金额、验证码等敏感信息不应直接明文展示在通知栏）
十一、这些维度该在什么阶段介入
十二、动态复查机制（新增）
清单目前的检查项大多是"是否已经……"这类存在性判断，但移动端的特殊性不只是"发布后不可收回"，还有**"环境在你看不见的地方持续漂移"**——系统版本在升级、厂商 ROM 策略在变、第三方 SDK 在悄悄更新。静态检查一次不够，需要配套的复查触发机制：
十三、小结
移动端App开发的特殊性，本质上来自"代码运行在你不能完全信任的环境里，而且发布之后你无法立刻收回，同时这个环境还在持续漂移"。这决定了：
很多在后端系统里理所当然"信任自己代码"的地方，在移动端要重新加一层"客户端不可信"的假设，并且这个假设必须落到服务端的具体防御动作上，而不是停在客户端不做什么；
可观测性不是锦上添花，而是你了解"用户设备上到底发生了什么"的唯一渠道，且必须有人真正在看、在响应；
发布策略要为"审核周期"和"版本碎片化"这两个后端系统不存在的约束留出应对空间，客户端自身的容错/兜底能力是审核周期内唯一的止损手段；
静态的检查清单会过期——它需要一套动态复查触发机制来配套，否则清单本身也会变成"曾经做过、现在早已不成立"的假象。
和原始清单一样，这份清单也不是终点——真正要做的，永远是回到"零、信任边界推导"这一步，针对你自己App的具体业务，重新走一遍这个推导过程，并且定期用"十二、动态复查机制"里的触发条件，检验这些结论是否依然成立。清单只能帮你不漏掉常见类别，替代不了持续的思考和复查。