3.2 十个高频问题门诊（下）：运行与计费类

和上一节的分工

上一节的问题集中在项目起步阶段，本节的五个问题则集中在项目跑起来之后：数据开始有了真实读写，函数开始承接真实流量，账单开始真实跳动。这类问题的共同特征是复现依赖运行环境，本地未必能看到，所以处方里会更依赖控制台里的数据与工具。下面逐问开诊。

症状：读写数据时报 permission denied，代码看起来完全正确，换台设备依然如此。

病因：Firestore 或实时数据库的安全规则拦下了请求。规则默认拒绝未授权访问，很多人开发期改过规则又忘了改回来，或者规则的判断条件和实际登录状态对不上。

处方： - 先去控制台规则编辑器通读当前规则，确认匹配逻辑和自己的预期 - 检查请求方是否真的完成了登录，匿名登录也算登录，未登录请求会被大多数规则拒绝 - 用规则模拟器做对照验证：同一条请求，模拟器里过不过、真机上过不过，差异就是线索 - 开发期可以临时放宽规则观察现象，但上线前必须收紧

检查清单：当前规则内容是否如你所想、登录状态是否有效、请求路径是否超出规则允许的范围、时间类条件是否因时区或服务器时间产生偏差。

症状：复合查询一跑就报错，错误信息里明确提示需要索引，并附有链接。

病因：涉及范围比较加排序，或多个字段组合过滤的查询需要复合索引。单字段索引自动维护，复合索引不会自动创建。

处方： - 点开报错信息附带的链接，控制台会预填好索引定义，一键创建即可 - 大数据量下索引构建需要时间，等状态变为可用再重测 - 把索引定义导出进版本库，换环境或重建项目时直接部署，省得再踩一遍

症状：函数本地跑得欢，一部署不是超时就是内存超限被强制终止。

病因：两类常见根因。一是默认运行配置对当前任务量确实不够；二是代码里有同步阻塞写法，比如异步调用没有正确等待、HTTP 函数迟迟不返回响应，导致函数提前被冻结甚至重复执行。

处方： - 核对函数的运行配置：内存规格与执行时长上限是否匹配任务量 - 排查阻塞写法：所有异步调用是否正确等待、响应是否及时返回 - 把耗时工作拆小：大任务分片处理，重活用队列思路而不是单函数硬扛 - 避免一次性把大数据全量载入内存，能流式就流式

症状：用量突然翻倍甚至更多，账单曲线陡增，代码却没大改。

病因：通常是三种情况。监听器没清理，客户端反复叠加长连接；函数互相触发形成循环，A 写库触发 B，B 又写回触发 A；或者公开接口没做校验被灌入垃圾数据，读写量跟着暴涨。

处方： - 打开控制台用量页，按产品和时间维度定位是哪一项在涨：读、写、存储还是出站流量 - 客户端检查监听器的取消逻辑，页面销毁、用户登出时必须退订 - 函数侧检查触发链，写入路径上明确排除会再次触发自己的文档 - 公开接口加校验与限流，别让外部随意写库

症状：通知时灵时不灵，或者彻底收不到，多设备表现还不一致。

病因：消息投递和三件事强相关：应用在前台和后台时消息的处理路径本来就不同；设备上的注册令牌会过期或失效；国产设备还有系统级推送通道的差异问题。

处方： - 前台收不到通知属正常现象，前台消息需要应用内自行处理展示 - 后台也收不到时，先检查令牌的获取与上报逻辑，令牌更新后要同步到服务端 - 测试时分场景做：应用在前台、退到后台、进程被杀，三种状态分别验证 - 国产设备上确认系统层通知权限与厂商通道配置，实际到达率以真机表现为准

运行期问题的共同套路是：先定位、再复现、后修复。用量页和规则模拟器是这一节最好用的两件工具，遇到说不清的问题，先让数据说话，再动手改代码。