很多时候，老百姓点开一个政务服务 App，如果半天没反应，第一反应就是一句“这系统又卡了”。这句话背后，能抵消我们多少个昼夜的辛苦开发。但如果用户感觉几乎是“秒回”，他们就会更愿意用，也会更信任政府数字化服务。
各种loading图镇楼
低延迟从来不是靠某个小技巧能解决的，而是架构设计、开发习惯和运维手段的综合结果。
1. 别让请求“绕远路”
政务系统里，一个请求如果要兜兜转转经过一堆服务，速度就会被拖垮。
比如企业在办营业执照，系统需要校验法人信息：
低效做法： API → 高效办服务 → 统一认证 → 用户中心 → 网关 → 数源服务 → 归口委办局系统 → 法人数据库
更优做法： API → 高效办服务（直接查库或调用缓存）
每多一次服务间的调用，就多几十甚至上百毫秒，用户等的焦虑，我们服务的线程也一直在阻塞。
建议：
高频调用的服务尽量合并或直连
核心办件流程要走最短路径
2. 常用数据要“放手边”
有些数据不是实时变的，比如个人基本信息、证照，完全没必要每次都去查库。
数据库查一次：100ms
Redis 查一次：2ms
差距就在这里。
建议：
优先用缓存（Redis、Memcached）
多层缓存：浏览器端、CDN、应用层都要用上
设置合理过期时间，既快又不会数据过期太久
3. 慢 SQL 是“隐形杀手”
我见过不少系统，卡住就是因为一条慢 SQL。
有个系统查一个事项，居然 SELECT *，全表上千万数据，结果整个接口“蜗牛速度”。
正确做法：只查需要的字段，加好索引。
建议：
避免复杂 join
合理利用索引
高并发读场景用主从分离
复杂统计尽量预计算存表
4. 用户先拿到结果，后台再“慢慢忙”
用户最关心的就是：这事儿办成没？
比如市民提交一个新生儿一件事：
关键路径就是：校验资料 → 落库 → 返回结果。
至于办件分发、短信通知、日志记录、统计分析，完全可以放到响应之后。
5. 请求要打包
前端调用接口，千万别逼着它一条一条拉。
比如报表查 12 个月的数据：
慢法： 串行调 12 次接口 → 12 秒
快法： 打包一次查完 → 1 秒
建议：
不要在前端通过多次接口调用拼装数据，在后端处理数据一次返回给前端
一些统计查询，后端查询缓慢的，可以通过 定时任务 或 消息队列 提前处理好
6. 传输别搞“大包袱”
接口里最常见的浪费：动辄返回几百 KB，其实用户只需要一个字段。更奇葩的，居然用 base64 编码把大文件塞进接口返回。
建议：
只传必要字段
文件内部传输用编码，实际使用时再读取物理文件
开启 gzip 压缩
高频调用场景用 gRPC 或二进制协议
7. 前端能做的事，不要放到后台
能在浏览器完成的事，尽量别走后台。
建议：
表单格式校验直接前端做
html、css、js、图片等静态资源利用好浏览器缓存
在前端处理图片压缩、文件打包
8. 提前准备“洪峰”
平时没什么压力，一到高考报名、医保缴费，瞬间就崩了。
建议：
提前准备扩容
合理做负载均衡
写在最后
老百姓不关心后台有多复杂，只关心点一下是不是“秒回”，老百姓少等一秒，政府服务的获得感就会多一分。