1. 先把情绪翻译成指标这个网站到底哪里让人抓狂标题里那口气我先咽回去咱们聊点有用的。事情是这样的前阵子接手一个站点前后折腾了两轮第一轮改完我觉得已经差不多了结果上线第二天又被用户骂回来于是有了这个“续”。这篇不聊情怀只聊网站性能优化这件事怎么从“我觉得慢”变成“我知道它慢在哪一行、慢多少毫秒”。如果你手上也有一个打开要转三圈、点一下要愣两秒、后台一看服务器负载又不高的站点这篇基本能照着抄。先说清楚这篇适合谁看写过前端也碰过后端、能看懂 Nginx 配置和一条 SQL 的初中级开发者最合适纯前端同学可以重点看第 2 章后端同学重点看第 3、4 章运维同学看第 3 章和第 5 章。全文的核心就一句话把用户嘴里的“卡”翻译成 TTFB、LCP、慢查询条数、错误率这四个能盯的数字然后一个一个往下压。我第一次接手时踩的最大坑是拿“页面能打开”当成“性能没问题”。实际上用户感知的慢和开发者看到的慢经常不是同一件事。开发者本地跑、内网访问、数据量小一切都是丝滑的用户在用旧手机、弱网、跨地域、首页要拉二十个接口。这两个世界的差距就是你被骂的原因。所以第一步永远不是改代码是建立同一个参照系。1.1 从“体感慢”到可量化的问题清单我一般的做法是先不碰代码花半天时间做三件事把模糊的抱怨切成具体条目。第一件拉真实用户数据。前端埋PerformanceObserver采 LCP、INP、CLS、TTFB 四个核心指标带上设备类型、网络类型、地区、页面路径按天聚合。没有真实数据就先看实验室数据但实验室数据只能当参考别当结论。第二件列出“用户抱怨的原话”。这句话很重要因为“打不开”和“点按钮没反应”和“图片一直转圈”是完全不同的三类问题对应前端渲染、接口阻塞、静态资源三个方向。我那次收到的原话里出现频率最高的其实是“点了提交之后不知道有没有成功”这根本不是性能问题是缺少反馈状态属于交互设计缺陷加个按钮 loading 和防重复提交就好了跟优化一毛钱关系没有。第三件把所有页面按“访问量 x 抱怨量”排个序只改前三个。你不可能一次改完改完也验证不过来。我第二轮就只盯首页、列表页、详情页三个其他页面先放着。埋点代码大概长这样不需要引第三方库原生 API 够用// 采集核心 Web Vitals上报到自己的日志接口 const report (name, value, extra {}) { navigator.sendBeacon(/api/perf, JSON.stringify({ name, value: Math.round(value), ts: Date.now(), path: location.pathname, ...extra })); }; new PerformanceObserver((list) { for (const entry of list.getEntries()) { report(LCP, entry.startTime, { element: entry.element?.tagName }); } }).observe({ type: largest-contentful-paint, buffered: true }); new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (!entry.hadRecentInput) report(CLS, entry.value * 1000); } }).observe({ type: layout-shift, buffered: true }); new PerformanceObserver((list) { for (const entry of list.getEntries()) { report(INP, entry.duration, { type: entry.name }); } }).observe({ type: event, buffered: true, durationThreshold: 40 }); // TTFB 用 navigation timing window.addEventListener(load, () { const nav performance.getEntriesByType(navigation)[0]; if (nav) report(TTFB, nav.responseStart - nav.requestStart); });sendBeacon的好处是页面关闭也不丢数据比fetch稳妥。上报接口本身要做得极轻落盘到日志文件再异步聚合别让它成为新的瓶颈——这一点很多人会忘最后监控系统自己把服务拖垮了。1.2 三张表把问题钉死在具体环节数据有了接下来我用三张表来做判断这个习惯用了好几年比任何工具都直观。第一张是分段耗时表把一次页面加载拆成 DNS、TCP、TLS、TTFB、内容下载、DOM 解析、首屏渲染。哪一段占比超过 30%就往那个方向查。阶段健康值超标先查什么DNS 解析 50ms域名解析服务、是否需要预解析TCP TLS 150ms是否复用连接、证书链长度TTFB 800ms服务端逻辑、数据库、下游依赖内容下载首屏 300KB静态资源体积、压缩、CDN首屏渲染LCP 2.5s关键资源阻塞、图片规格、字体第二张是接口耗时分布表。同一个接口的 P50、P95、P99 拉出来如果 P50 是 80ms 而 P99 是 3s那问题不在常规逻辑在长尾——可能是慢查询、可能是下游超时重试、可能是 GC 抖动。我那次就是 P50 只有 60msP99 高达 4.2s最后定位到是某个统计查询在特定参数下走了全表扫描。第三张是错误与重试表。5xx 比例、超时次数、重试次数分开统计。重试次数这个指标特别容易被忽略但它会放大故障一个接口超时 3 次重试下游本来 100 QPS 瞬间变成 300 QPS雪崩就是这么来的。注意不要在同一天既改代码又看数据。改完至少要观察一个完整的业务高峰否则你看到的是缓存预热后的假象。2. 前端这层把首屏加载拆到骨头里前端这块我吃过最大的亏是一直盯着总包体积忽略了首屏实际加载的资源。整个项目 8MB 的 JS 不可怕可怕的是首页一进来就要下载其中 3MB而这 3MB 里有 2MB 是后台管理模块的图表库。用户根本用不到但你让他等了。先给结论首屏性能优化的核心不是“让所有东西变快”而是“让不该在首屏出现的东西晚点出现”。这是两个完全不同的思路前者是压缩、调优、换 CDN收益有限后者是拆分、延后、按需收益往往是数量级的。2.1 资源预算与打包产物分析我现在做任何项目第一件事是给首屏定一个资源预算写进项目文档进 CI 卡口。没有预算的优化三个月后一定回退。我的常用预算供参考针对内容型站点工具型后台可以放宽类别首屏预算gzip 后说明JS170KB包含框架运行时CSS50KB关键 CSS 内联其余异步字体100KB最多两个字重优先系统字体图片300KB首屏可见区域WebP/AVIF首屏接口总耗时500ms并发请求串行会叠加预算怎么定不是拍脑袋。我的算法是目标 3G 网络下 2 秒内完成首屏加载3G 实际有效带宽按 400KB/s 估算2 秒就是 800KB扣掉 TCP/TLS 握手和渲染时间留给资源的份额大概 600KB。这个数字可以直接推导不是玄学。有了预算就要看打包产物。用构建工具的 analyze 能力生成体积报告重点看三件事最大的一块是谁、有没有重复依赖、有没有把只在某个页面用的东西打进主包。我那次看报告发现三个不同的图表库同时存在加起来 1.4MB实际业务只用了其中一个的折线图。删掉两个换成轻量方案直接省下 900KB。另外有个细节moment这类库的语言包、lodash的全量引入都是历史遗留的高频问题。前者用构建插件裁掉不需要的 locale后者改成按方法引入或者换更轻的替代一次能省几百 KB改动量还很小属于性价比极高的活。2.2 关键渲染路径上的几个高频病灶资源体积只是第一层真正卡住首屏的往往是渲染路径。我按出现频率从高到低列几个都是我在实际项目里反复遇到的。第一个同步阻塞脚本。script不带async或defer放在 head 里浏览器必须下载并执行完才能继续解析 HTML。这玩意儿对首屏的杀伤力极大。改法很简单非关键脚本加defer纯统计类加async必须在解析前执行的极小脚本直接内联。第二个关键 CSS 没内联。首屏需要的样式要等整个 CSS 文件下载完才生效这段时间页面是白屏的。做法是把首屏用到的样式抽出来内联进 HTML剩下的异步加载。手工抽容易漏一般用构建插件自动处理。第三个图片没有明确尺寸。img不写width/height图片加载完布局会跳CLS 直接爆表。这个改起来最便宜加两个属性的事但很多项目就是不做。第四个字体阻塞。自定义字体默认会有一段时间文字不可见FOIT用户看到的是空白。加font-display: swap让文字先用系统字体渲染字体加载完再替换视觉上会闪一下但比白屏好得多。更好的做法是首屏干脆用系统字体栈中文场景下自定义字体的收益本来就不高。/* 字体加载策略先渲染再替换避免 FOIT */ font-face { font-family: BrandSans; src: url(/fonts/brand-sans.woff2) format(woff2); font-display: swap; unicode-range: U0000-00FF; /* 只加载拉丁字符中文走系统字体 */ }unicode-range这个属性值得单独说一下。中文字体动辄几 MB全量加载基本不可行。用unicode-range限定只加载西文字符中文交给系统字体这是中文站点最务实的选择。至于字体子集化只有在标题固定、字数可控的场景才划算正文用子集化容易漏字别轻易上。2.3 图片、字体与第三方脚本这三样是首屏体积的三大户单独拎出来说。图片这块格式优先 AVIF其次 WebPJPEG 兜底用picture做降级。尺寸一定要按实际展示尺寸出图别拿 2000px 的原图塞进 300px 的容器。响应式用srcset配sizes让浏览器自己挑。懒加载只给首屏以下的图加首屏图加懒加载反而会拖慢 LCP这是很多人搞反的地方。!-- 首屏图不懒加载明确尺寸多格式降级 -- picture source srcset/img/hero-800.avif 800w, /img/hero-1600.avif 1600w sizes(max-width: 768px) 100vw, 800px typeimage/avif source srcset/img/hero-800.webp 800w, /img/hero-1600.webp 1600w sizes(max-width: 768px) 100vw, 800px typeimage/webp img src/img/hero-800.jpg width800 height450 alt首屏主图 fetchpriorityhigh decodingasync /picturefetchpriorityhigh是给 LCP 元素用的明确告诉浏览器“这张最重要先下它”。默认情况下浏览器给图片的优先级是 low你不标它可能排在几个无关脚本后面。第三方脚本是另一个大坑。统计、客服、广告、A/B 测试每个都说自己“只有几十 KB”加起来就是一两兆而且它们通常在网络空闲时才加载导致首屏指标看着还行但用户实际交互时卡顿。我的处理原则是首屏不需要的第三方脚本一律延迟到用户首次交互或load之后再注入并且全部加async绝对不允许同步嵌入。// 延迟加载非关键第三方脚本 const loadDeferred () { const scripts [ https://static.example.com/analytics.js, https://static.example.com/support-widget.js ]; scripts.forEach((src) { const s document.createElement(script); s.src src; s.async true; document.body.appendChild(s); }); }; // 用户有交互迹象或页面完全加载后再拉 [pointerdown, keydown, scroll].forEach((evt) window.addEventListener(evt, loadDeferred, { once: true, passive: true }) ); window.addEventListener(load, () setTimeout(loadDeferred, 3000));提示如果某个第三方脚本提供了“延迟加载”的官方参数优先用官方的别自己包一层否则容易踩到它的初始化时序问题。3. 服务端与链路TTFB 为什么总是压不下来前端能做的做完了你会发现指标卡在一个地方不动了——TTFB。因为剩下的时间根本没花在浏览器里全在服务端。这一章是我第二轮改动的重点也是收益最大的一块。先说一个判断标准TTFB 超过 800ms基本可以认定问题在服务端或链路上跟前端没关系。这时候再去看 JS 体积、看图片压缩纯属浪费时间。我第一轮就犯了这个错把首页 JS 从 1.2MB 压到 400KBLCP 只从 4.8s 降到 4.3s因为真正的大头是 2.6s 的 TTFB。3.1 一次请求都经过哪些环节要压 TTFB先得知道时间花在哪。一次请求从用户点击到首字节返回大致经过这些环节我按经验给个正常占比环节正常耗时常见问题DNS 解析10-50ms无预解析、解析服务慢TCP 握手20-100ms跨地域、未复用连接TLS 握手30-150ms证书链过长、未开会话复用接入层5-30ms反向代理规则过多、日志同步写应用处理50-500ms业务逻辑、序列化、下游调用数据库10-300ms慢查询、连接等待、锁竞争跨地域这个因素经常被低估。用户在南边、服务器在北边物理往返一次就是 30-40msTCP 加 TLS 至少四五个往返光握手就 150ms 出去了。这部分靠改代码解决不了只能靠就近接入和连接复用。静态资源走 CDN 是常识但很多人忘了API 响应也可以做边缘缓存尤其是那种读多写少的配置类、字典类接口缓存到边缘节点TTFB 直接从 200ms 干到 20ms。还有一个很少被提及的点TLS 会话复用。没开启的话每个新连接都要完整握手开启后恢复会话只需要一个往返甚至零往返。配置通常就一行开关收益在弱网环境下非常明显。3.2 连接池、超时与限流参数怎么定参数这块我不喜欢抄别人的配置因为机器规格、业务特征差别太大。我给几个可以推导的方法。连接池大小。经典公式是连接数 CPU 核心数 × 2 磁盘数现在磁盘基本都是 SSD磁盘数按 1 算。8 核机器就是 17 左右取整配 20。这个数字的含义是“能同时干活的连接数”配太大反而会因为上下文切换变慢。很多人一看 QPS 高就把池子调到 200结果数据库侧全是等待吞吐反而下降。超时时间。原则是逐层递减前端 10s 网关 5s 应用 3s 下游 1s。这样任何一层出问题都是最内层先超时返回外层拿到明确的失败信号而不是全部一起卡死。我见过所有层都配 30s 的项目一次下游抖动直接导致线程池打满整个服务不可用。限流阈值。不要拍脑袋写个 1000。算法是先压测出单机在 P99 可接受时的最大 QPS打个 70% 折扣作为单机阈值再乘以实例数得到集群阈值。折扣是留给突发流量和 GC 停顿的余量。# 应用层超时配置示例数值按逐层递减原则 server: tomcat: threads: max: 200 # 与连接池匹配别超过池子太多 connection-timeout: 3000 http-client: connect-timeout: 500 # 建连要快失败就快速重试 read-timeout: 1000 # 下游读超时必须小于本层总超时 max-retries: 1 # 只重试 1 次避免放大流量 pool-max: 50 rate-limit: qps-per-instance: 700 # 压测 1000 的 70% burst: 1400 # 允许 2 倍突发注意重试次数一定要和限流一起考虑。重试 3 次相当于把下游流量放大到 4 倍如果下游本来就快撑不住了重试就是补刀。正确做法是只对幂等请求重试且重试要有退避最好带随机抖动。3.3 日志与链路追踪的落地方式没有链路追踪的排查全靠猜。我这次能在一晚上定位到那个 4.2s 的 P99靠的就是给每个请求打了一个 trace id从头串到尾。落地其实不难最低成本方案网关生成 trace id塞进请求头应用层放进日志的 MDC日志上下文所有下游调用透传这个头日志采集后按 trace id 聚合。不需要上复杂的系统一个 grep 就能还原整条链路。# 按 trace id 还原一次慢请求的完整链路 grep trace_id7f3a9c21 /var/log/app/*.log | sort -k1,2 | \ awk {print $1, $2, $NF}日志内容我建议至少包含这几项trace id、接口路径、耗时、状态码、下游调用耗时、慢查询标记。耗时超过阈值比如 500ms的请求单独打一条 WARN 日志方便快速捞出慢请求样本不用全量翻。采样策略也要想清楚。全量采集在高 QPS 下成本很高我的做法是正常请求 1% 采样慢请求和错误请求 100% 采集。这样既控制了量又保证有问题时一定有数据。4. 数据库与缓存慢查询才是隐形杀手到这一层基本就是“为什么接口有时候快有时候慢”的答案了。我统计过自己经手的问题接口耗时异常里六成以上能追到数据库剩下一部分是下游服务和 GC。数据库这块的特点是平时看着没事一到数据量涨起来或者并发上来问题集中爆发。4.1 慢 SQL 的定位与索引复核定位慢 SQL 有两条路一条是数据库自带的慢查询日志一条是应用侧的耗时埋点。前者更准后者更及时。我一般两个都开。慢查询阈值建议先设 200ms跑一天看看量如果量太大说明阈值太低往上调到 500ms如果量是零说明你的问题不在 SQL往下调到 100ms 再看。这个调法比直接看默认值有意义。找到慢 SQL 之后第一件事是看执行计划。重点看三个字段type是不是 ALL全表扫描、rows预估扫描行数超过一万就要警觉、extra出现 Using filesort、Using temporary 基本都有优化空间。-- 查看执行计划重点关注 type / rows / Extra EXPLAIN SELECT id, title, created_at FROM article WHERE status 1 AND category_id 12 ORDER BY created_at DESC LIMIT 20; -- 针对上面这条联合索引应该这样建 -- 等值条件在前排序字段在后遵循最左前缀 ALTER TABLE article ADD INDEX idx_status_cat_ctime (status, category_id, created_at);索引这块有三个我踩过的坑值得单独说。第一索引不是越多越好。每个索引都会拖慢写入而且优化器在多索引时可能选错。我给的经验值是单表索引不超过 5 个超过就要审视是不是查询模式出了问题。第二区分度低的字段不要单独建索引。像status只有 0 和 1单独建索引基本没用优化器大概率还是走全表。它应该作为联合索引的最左列配合高区分度字段一起用。第三函数和隐式转换会让索引失效。WHERE DATE(created_at) 2024-01-01这种写法索引直接作废改成范围查询created_at 2024-01-01 AND created_at 2024-01-02才能用上。隐式转换更隐蔽字段是字符串类型却传了数字索引一样失效这种问题看执行计划才能发现。4.2 缓存策略与三个经典事故缓存能解决大部分读多写少的场景但它也会引入新问题。我列三个实际遇到过的都是“加了缓存反而更糟”的典型案例。第一个缓存穿透。大量请求查一个不存在的 key缓存不命中全都打到数据库。解法有两种一是空结果也缓存给个短 TTL比如 60 秒二是用布隆过滤器前置拦截。前者实现简单后者更彻底看场景选。第二个缓存击穿。某个热点 key 过期的瞬间大量并发同时回源。解法是回源时加互斥锁只放一个请求去查库其他等结果。或者干脆热点数据不设过期时间靠后台任务主动更新。第三个缓存雪崩。大批 key 在同一时刻集体过期数据库瞬间被打满。解法是 TTL 加随机抖动把过期时间打散。这个改动成本极低但很多人不做。// 缓存读取的标准写法空值缓存 互斥回源 TTL 抖动 async function getArticle(id) { const key article:${id}; const hit await cache.get(key); if (hit ! null) return hit __NULL__ ? null : JSON.parse(hit); // 互斥锁只放一个请求回源 const lockKey lock:${key}; const locked await cache.set(lockKey, 1, NX, EX, 5); if (!locked) { await sleep(50); return getArticle(id); // 短暂等待后重试实际项目要限制重试次数 } try { const row await db.query(SELECT * FROM article WHERE id ?, [id]); if (!row) { await cache.set(key, __NULL__, EX, 60); // 空值短缓存防穿透 return null; } const ttl 1800 Math.floor(Math.random() * 300); // 30 分钟 ± 5 分钟抖动 await cache.set(key, JSON.stringify(row), EX, ttl); return row; } finally { await cache.del(lockKey); } }4.3 缓存 TTL 与容量估算TTL 定多久我一直用一个朴素的判断能容忍多旧的数据就定多久。商品详情容忍 30 分钟库存不能容忍 1 秒配置字典可以容忍一天。这个判断来自业务不是技术。容量估算也有公式可循。假设缓存 100 万条记录单条序列化后平均 2KB那就是 2GB 内存。加上 Redis 自身的开销大约 20%-30%需要预留 2.6GB。如果内存只有 4GB那就得考虑淘汰策略和只缓存热数据。热数据怎么定用访问频率排序取贡献 80% 访问量的那部分 key。实际经验是这部分通常只占总量 10%-20%把这部分缓存好命中率就能到 85% 以上。盲目全量缓存命中率上不去内存还吃满得不偿失。淘汰策略方面纯缓存场景用allkeys-lru最稳妥。如果缓存里还存了别的东西比如分布式锁、会话就要用volatile-lru只淘汰带过期时间的避免把锁给淘汰了——这个坑我踩过锁被淘汰导致互斥失效差点出事故。5. 常见问题与排查技巧实录这一章是纯经验都是那种文档里不会写、但排查时能救命的东西。我按“症状 → 可能原因 → 怎么验证”整理成表遇到问题时可以直接对着查。5.1 典型症状速查表症状优先怀疑验证方式首次打开慢二次打开很快静态资源没缓存看响应头 Cache-Control所有人都慢服务端或数据库看服务整体指标不是个例只有部分地区慢链路、接入节点按地区拆分 TTFB偶发卡顿规律性出现定时任务、GC、缓存集中过期对齐时间点看监控接口 P50 正常 P99 高慢查询、长尾依赖捞慢请求样本逐条看页面加载完但点不动主线程被长任务占用录 Performance 看长任务图片一直转圈图片服务、格式不支持看 Network 里图片请求状态提交后没反应交互反馈缺失不是性能问题手动点一下看有没有 loading表格里最后两条我想多说两句。很多人把交互问题当性能问题来优化改了半天没效果。判断方法很简单打开开发者工具录制看点击后主线程有没有被长时间占用。如果没有那就是交互反馈的问题加个 loading 状态就能解决一分钟的事。5.2 几个反直觉的坑坑一压缩开了反而更慢。Brotli 压缩率比 gzip 高但压缩耗时也长。对于动态接口响应实时 Brotli 压缩可能让 CPU 飙高、响应变慢。正确做法是静态资源预压缩动态响应视体积决定小于 1KB 的响应干脆别压压了反而变大。坑二HTTP/2 下域名分片适得其反。老优化手段里有个“静态资源分多个域名”目的是突破浏览器并发限制。HTTP/2 下多路复用已经解决了这个问题再分片反而要建多条连接多花握手时间。坑三预加载用过头。preload是告诉浏览器“这个很重要优先下”但如果预加载了实际没用到的资源会抢占带宽让真正需要的资源变慢。我见过一个页面预加载了 12 个资源结果首屏图排在最后。原则是预加载数量不超过 3 个只给首屏关键资源。坑四日志级别设成 DEBUG 上线。这个听起来很低级但真遇到过。DEBUG 级别下每次请求打几十行日志同步写磁盘QPS 一上来 IO 直接打满接口耗时翻倍。上线前检查日志级别应该写进发布清单。坑五以为 CDN 缓存了其实没有。CDN 是否缓存取决于响应头。如果源站返回Cache-Control: no-cache或者带了Set-CookieCDN 一般不会缓存。验证方法是连续请求两次看响应头里的X-Cache是 HIT 还是 MISS。我第一次配置时忘了去掉Set-Cookie静态资源一次都没缓存上白折腾两天。6. 优化落地节奏与我的个人习惯改到这里指标基本都进绿区了。但我想说的是优化这件事最难的不是技术是怎么让改动安全上线、怎么让效果不回退。第一轮我改完直接全量发布结果一个缓存配置写错首页白屏了 8 分钟。第二轮学乖了老老实实灰度。6.1 分阶段上线与灰度我的节奏一般是这样先上监控和日志观察三天确认数据可信然后改低风险的图片、字体、静态资源缓存观察一天再改中风险的接口合并、缓存策略灰度 10% 流量观察一天最后改高风险的数据库索引、连接池、超时配置灰度 5% 观察两小时没问题再逐步放量。灰度期间重点盯四个指标错误率、P99 耗时、慢查询数量、CPU 使用率。任何一项异常就回滚不犹豫。数据库索引这类改动要特别注意加索引本身会锁表大表尤其明显尽量用在线 DDL 工具在低峰期执行。注意回滚方案要在发布前就准备好不是出问题再想。配置类的改动把旧配置备份一份放旁边代码类的改动确保上一个版本随时可回。6.2 监控看板与告警阈值设置监控看板我只放四块多了没人看核心页面指标趋势、接口耗时分布、错误率与重试、资源水位。每块不超过 6 个图一眼能看完。告警阈值我设得比较保守宁可漏报不要误报误报多了大家就不看了。具体是错误率连续 5 分钟超过 1% 告警P99 连续 10 分钟超过基线 2 倍告警慢查询每分钟超过 50 条告警CPU 连续 15 分钟超过 80% 告警。全部带“连续 N 分钟”的条件避免瞬时抖动触发。基线这个事值得说一下。不要用固定值当基线用上周同期的数据当基线这样能自动适应业务增长和周期波动。周末的流量和工作日完全不同固定阈值一定会误报。6.3 一些个人经验最后分享几个我自己的习惯不一定对但用着顺手。第一每次优化只改一个变量。同时改五处指标好了你不知道是哪处的功劳指标坏了你不知道是哪处的锅。慢一点但靠谱。第二优化前先记录基线。我习惯在动手前截一张监控图存着改完对比。没有基线就没法证明效果也没法向别人解释你干了什么。第三别追求满分。LCP 从 4.8s 压到 2.3s用户已经感知不到明显卡顿了再往下压到 1.8s 要付出的成本可能是前者的三倍。找到那个“用户感知的拐点”就停手把精力放到别的地方。我的经验拐点大概在首屏 2.5s 以内、接口 P95 在 500ms 以内、错误率低于 0.1%到了这个区间继续优化的投入产出比就很低了。第四把优化固化成规范。资源预算写进 CI超了就构建失败日志级别、缓存响应头写进发布检查清单新增第三方脚本要走评审。不然三个月后一切打回原形。这件事我在第一个项目上吃过亏改完很爽半年后接手的人又加了一堆同步脚本全白干。第五也是我觉得最重要的一条先确认问题是不是性能问题。那次“点了提交没反应”的抱怨占了三分之一解决它只花了一个下午加个 loading 状态和防重复提交但用户满意度提升比后面所有优化加起来都明显。技术人容易一头扎进指标里忘了用户真正在意的可能只是“你让我知道它在转”。