云函数响应无法达毫秒级，需通过预热、精简初始化、跳过json解析、加数据库索引及规范返回值来压测稳定p95≤200ms。
云函数响应做不到毫秒级——冷启动、网络传输、平台调度都会带来几十到几百毫秒的固有延迟。所谓“毫秒级调优”，实际是压测后把 P95 响应稳定控制在 200ms 内，避免卡顿感。关键不在代码快，而在绕过平台瓶颈。
云函数冷启动怎么绕开？别等它发生
uniCloud 的冷启动无法完全消除，但可以大幅降低触发概率：
- 阿里云/腾讯云环境默认不支持常驻实例，
exports.main每次都是新进程，首次调用必然有 100–400ms 延迟 - 高频函数（如登录校验、权限检查）必须开启「预热」：在 HBuilderX 中右键云函数目录 → 「设置云函数配置」→ 勾选「启用预热」，并设为每 5 分钟触发一次空请求
- 避免在
exports.main外层 require 大量模块（比如整个uni-id或数据库连接池），这些会在每次冷启动时重复加载；把初始化逻辑移到main内部 + 缓存变量 - 不要用
require('./utils')引入含fs.readFile或同步 HTTP 请求的工具模块——它们会阻塞事件循环，放大冷启动感知
event.data 解析慢？直接禁用 JSON 解析
前端传参如果只是简单对象（如 { userId: 'u123', action: 'view' }），云函数默认仍会走完整 JSON.parse 流程。可跳过这步：
- 前端调用时确保
data是 plain object，不嵌套函数、Date、undefined、RegExp - 云函数内不依赖
JSON.stringify(event.data)做日志，改用console.log('data:', event.data.userId)直接取值 - 若需深拷贝或校验，用
Object.assign({}, event.data)替代JSON.parse(JSON.stringify(event.data))，后者多一次序列化+反序列化 - 注意：
event.data已是解析后的对象，不是原始字符串，别再手动JSON.parse(event.data)—— 这会导致TypeError: Converting circular structure to JSON
数据库查询为什么卡住？.get() 前必须加索引
云数据库的 .where().get() 不加索引，哪怕只查一条，也可能耗时 300ms+，尤其在数据量超 1000 条后：
- 在 DCloud 控制台进入「云数据库」→ 选择集合 → 「索引管理」→ 添加单字段索引，字段名必须和
where中完全一致（如where({ userId })就建userId索引） - 复合查询（如
where({ userId, status: 'active' })）必须建复合索引，顺序要和 where 条件顺序一致 - 避免
.orderBy('create_time').limit(10)不带where—— 这会全表扫描，P95 延迟飙升至秒级 - 测试时用
console.time('db')/console.timeEnd('db')包裹.get()，确认是否真卡在 DB 层
返回值里藏了 Date 或 Buffer？序列化直接拖垮性能
云函数返回值必须是 JSON 可序列化的纯对象。一旦包含不可序列化类型，引擎会静默转为 null，但过程本身消耗 CPU：
- 禁止
return { time: new Date(), data: result }—— 改成return { time: Date.now(), data: result } - 文件上传后返回的
fileID是字符串，但如果你顺手调了uniCloud.uploadFile返回的tempFilePath对象，它含 Buffer，不能直接 return - 使用
uniCloud.database().collection('xxx').add()后，别直接return res，因为返回值含_idObjectId 类型，需先JSON.parse(JSON.stringify(res))或用res.id提取字符串 ID - 调试时加一行
if (typeof res === 'object') console.log('return size:', JSON.stringify(res).length)，超过 20KB 就该分页或精简字段
真正影响用户体验的，往往不是代码执行时间，而是冷启动时机、数据库无索引扫描、以及返回值隐式序列化开销。这些点不处理，再优化 for 循环也没用。
