App 做出来了不好用，问题常常在后端

很多企业做 App 的过程是这样的：找团队做前端，界面漂亮、交互流畅，验收时演示一切正常。上线两周后投诉开始出现：员工要记两套账号，App 一套、电脑端一套；审批在 App 里点了同意，电脑端还得再点一次；客户在 App 里看到的价格和销售在系统里报的不一样；推送通知十次有三次收不到，补货提醒错过了。

这些问题的共同点是，它们都不在前端。App 只是外壳，真正决定体验的是它背后连着什么。如果 App 单独建了一套用户体系、单独存了一份商品和价格、单独走了一条消息通道，那么它注定会变成一个信息孤岛，用的人越多，维护成本越高。判断一个 App 是否已经成了孤岛，看三个现象：有没有第二套账号、有没有第二份主数据、有没有第二条审批链路。三个里出现任意一个，集成问题就已经存在了。

所以做 App 的正确顺序不是先画界面，而是先定三条链路：账号从哪来、消息怎么发、数据以谁为准。这三条链路定清楚，前端做多快都不会跑偏；定不清楚，界面做得再精致，也只是把混乱包装得更漂亮。安徽好牛软件有限公司在评估这类项目时，会先花两三天走一遍三条链路，往往在这阶段就能发现后面三个月的返工点。

先画三条链路：账号、消息、数据

三条链路是 App 与后端集成的骨架。每条链路都要回答四个问题：数据从哪来、存放在哪、谁有权改、异常怎么处理。回答完这四个问题，技术方案自然就出来了，不需要一上来讨论用什么框架。

账号链路最常被低估。技术上做统一账号并不难，难的是历史包袱：ERP 里有一套账号、OA 里有一套、老系统里还有一套，员工入职要开三个账号，离职要关三个，漏关一个就是安全隐患。App 上线如果新建第四套，这个坑会更深。可行的路径是先建一份人员主数据，把三套老账号映射进去，App 只认这一份，老系统逐步改造而不是一次性替换。

数据链路的核心原则只有一句：准数只有一个地方。App 可以缓存价格和库存用于提升体验，但缓存必须有过期时间，且下单时必须回源校验。常见的坑是 App 侧缓存了价格，销售在后台改了促销价，用户在 App 里看到旧价并下了单，最后要么亏钱发货，要么引发投诉。规则要写死：所有涉及金额和库存的写入操作，必须由服务端校验，客户端传来的价格一律不信。

统一账号：四种方案与选择标准

统一账号有四种常见方案，复杂度和适用场景差别很大。选错的代价是上线后不断打补丁，最后变成四不像。选之前先数清楚三件事：现有系统几套、用户规模多大、有没有对外用户（客户、经销商）。

选择标准可以简化成一条线：内部员工为主、系统不超过五套，单点登录够用；有大量外部用户（客户、经销商、安装师傅），用托管身份服务更省事，短信验证码、第三方登录、风控都能直接拿到；组织层级复杂、权限要精细到岗位和数据范围，才考虑身份中台。跳过前两级直接上中台，是这类项目最常见的过度设计。

权限模型也要在账号阶段定清楚。App 端的权限通常是「这个人能看到哪些数据、能做哪些操作」，比电脑端更粗，但必须与后台同源。常见错误是 App 里另写一套权限判断，结果后台调整了岗位，App 里还是旧权限，出现越权查看。正确做法是权限判断放在服务端，App 只负责展示和发起请求，每次请求都带令牌，服务端判权。

消息与推送：到达率的三道坎

推送看起来是最简单的功能，实际是投诉最多的功能。用户说没收到，排查下来通常卡在三道坎上：消息有没有发出去、有没有送到设备、送到了有没有被折叠或忽略。这三道坎要分别治理，混在一起排查永远找不到原因。

第一道坎是发送侧。业务系统产生待办后，要通过统一消息服务发出，而不是各系统直连推送通道。统一消息服务做三件事：去重（同一条待办不重复推）、分流（重要消息走多通道，普通消息走单通道）、留痕（记录发送时间、目标、结果）。没有留痕，用户说没收到时无法自证。

第二道坎是通道侧。推送通道本身有成功率限制，安卓各厂商通道、iOS 通道、短信通道的成功率差异很大。工程上的做法是主备双通道：推送失败后延迟若干秒通过备用通道补发，重要消息（审批、告警、支付结果）再叠加短信兜底。这里要注意成本，短信按条计费，只给真正重要的消息用，不要把所有通知都发短信。

第三道坎是用户侧。用户关闭了通知权限、手机省电策略杀掉了后台进程、消息被系统归入不重要分类，这些都不是技术能强制的。可行的应对是：首次登录时引导开启权限并说明用途；App 内保留消息中心，所有推送的消息都能在站内查到；关键待办在 App 首页用红点常驻，不依赖推送。这三条做完，即使推送失败，业务也不会断。

还有一个容易被忽略的细节：消息要有明确的失效时间。三天前的待办今天再推给用户，只会造成打扰。统一消息服务应该支持有效期，过期未读的消息转为站内汇总，不再推送。这个小设计能显著降低用户关闭通知权限的比例。

中台要不要建：三种形态与判断门槛

中台这个词被用得太泛，实际上企业真正需要的往往只是其中一小块。把中台拆成三种形态看，决策会清楚很多：业务中台（订单、商品、库存等共享业务能力）、数据中台（统一指标与数据服务）、技术中台（账号、消息、文件、日志等基础能力）。App 项目最常需要的是第三种，偶尔需要第二种，很少需要第一种。

判断要不要建，用一条经验规则：同一个功能被第三个前端重复实现时，才值得抽出来做共享服务。第一个前端做的时候直接写，第二个前端复制改一改，第三个前端出现时再抽。提前抽取的代价是抽象错误——规则还没稳定就固化，后面每次业务调整都要改中台，改一次影响所有前端，比重复实现更痛。

业务中台尤其要谨慎。它要求企业对业务规则有清晰的、稳定的定义，而多数中小企业的规则还在随市场变化调整。这类企业建业务中台的结果通常是：中台做了一年，业务已经变了两轮，上线即过时。更务实的做法是把共享逻辑做成库或服务，不做成平台，需要时升级，不需要时不影响。

接口契约与联调排期

集成项目超期，八成超在联调。前端等接口、后端等确认、字段对不上、错误码没定义，来回一轮就是三天。解决靠的不是加班，而是把接口契约提前定死，并且用工具而不是口头来传递。

接口契约至少要包含六项：请求地址与方法、入参与出参的字段类型和是否必填、错误码清单与含义、鉴权方式、分页与排序规则、幂等要求。其中错误码最容易被省略，导致前端只能笼统提示「操作失败」。可行的做法是按业务域划分错误码段，每个码对应一句用户能看懂的话，前端直接展示，不用猜。

联调排期要留出三段缓冲。第一段是契约评审，两到三天，前后端和业务方一起过一遍字段，把歧义在这阶段消掉。第二段是 Mock 联调，前端先用模拟数据跑通页面，不等后端。第三段是真机联调，按业务场景走通端到端流程，每通一个场景打一个勾。三段做完，正式提测时的问题数量通常能减少一半以上。

还有一个工程细节值得写进合同：接口变更必须走版本管理。上线后新增字段可以兼容，删除或改类型的字段必须升版本并保留旧版本至少一个版本周期。很多 App 的线上事故来自后端改了一个字段含义，老版本 App 还在用，直接白屏。App 不像网页可以随时刷新，用户手机上的版本可能落后半年，这个现实必须在接口设计时就考虑进去。

常见问题解答

Q1：已经有 ERP 和 OA，做 App 一定要建中台吗？

不一定。先看重复功能有几项。如果 App 只需要登录、待办、审批、报表四类能力，用单点登录加一组接口就能满足，不需要中台。中台的价值在规模效应，系统越多、重复越多，收益越大。两三套系统的企业建中台，通常是把简单问题复杂化，维护成本反而超过收益。可以先做接口层，把 ERP 和 OA 的能力包装成标准接口给 App 用，这一步的工作量远小于建中台。

Q2：App 用户和后台员工是两批人，账号怎么设计？

分成两类主体，共用一套身份基础设施。员工走内部账号，绑定组织与岗位，权限按角色和数据范围控制；外部用户（客户、经销商、安装师傅）走外部账号，用手机短信验证码登录，绑定客户编号或经销商编号。两类主体在权限模型上分开，但在认证、令牌、审计日志上共用一套。这样既不混淆权限边界，也不用维护两套基础设施。

Q3：推送到达率要求多少才算正常？

分通道看。iOS 在用户授权的前提下，正常水平在 85% 以上；安卓受厂商通道和省电策略影响，能做到 70% 已属良好，个别机型会更低。所以不要把业务关键流程押在推送上，审批、支付结果这类必须有站内消息和短信兜底。衡量指标建议用「关键消息触达率」，即关键消息在 10 分钟内被用户看到的比例，这个数字比推送成功率更贴近业务。

Q4：接口联调总是超期，怎么排计划更靠谱？

把联调拆成可验收的小段，而不是一个大阶段。做法是：先定契约并评审通过，再用模拟数据让前端独立跑通，最后按业务场景逐个联调，每个场景有明确的完成标志。计划里给每段留 20% 缓冲，接口数量超过 50 个时按业务域分组并行。另外，把接口文档作为交付物写进合同，不交付文档视为未完成，这一条能显著减少后期的口头扯皮。

Q5：老系统没有接口，App 怎么取数？

三种做法，按侵入性从低到高。一是数据库只读视图，直接读老库的视图或中间表，不改原系统，风险最低，但要注意别读业务表的事务中间状态。二是定时导出文件再入库，适合数据量小、时效要求不高的场景。三是让原厂商开放接口，最规范但常涉及费用。前两种在项目里用得最多，前提是要约定只读账号、访问频率上限和字段口径，避免给老系统带来压力。

App 的体验问题，最后都会回到三条链路上：账号是不是一套、消息是不是一条、数据是不是一份。这三条定清楚，前端换几版都不影响骨架；定不清楚，再漂亮的设计也撑不住日常使用。集成工作没有多少技术难点，难的是把边界和口径提前写下来，并且让所有参与方按同一份契约做事。

安徽好牛软件有限公司在合肥做 App 与企业系统集成，见过最多的返工不是写错代码，而是账号和主数据各建一套。先把这三条链路画出来，再决定投多少钱做界面，是更省钱的顺序。

更多资料可访问官网：www.niuniuchuantu.com