背景 大表格卡顿通常来自渲染数量、响应式开销或频繁派生计算。先区分瓶颈，再决定虚拟列表、分页还是数据模型调整。 核心判断 只渲染可见窗口并保留适当 overscan。 对不可变大数组使用 shallowRef，替换数组触发更新。 行 key 稳定，昂贵格式化与计算按实际依赖缓存。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 const rows = shallowRef<Row[]>([]); const visibleRows = computed(() => rows.value.slice(start.value, end.value)); 边界与误区 切片只是虚拟列表的局部逻辑，还要维护滚动占位、行高和焦点。shallowRef 的深层原地修改不会自动更新，必须遵守不可变替换约定。 验证方式 在目标移动设备测试大数据滚动、排序和选中状态；记录长任务与内存，同时验证键盘导航、可访问性和屏幕尺寸变化。 小结 使用虚拟列表、稳定 key 和服务端筛选，避免把整份深层对象传给每个单元格。
背景 一个函数看起来复杂，不代表它是热点。优化之前需要固定请求模型，让采样结果可以解释和复现。 核心判断 记录二进制版本、构建参数、负载与 CPU 拓扑。 先看调用树和时间占比，再按假设做一次最小改动。 同步观察吞吐、尾延迟与分配，避免局部收益换来整体退化。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 perf record -F 99 -g -- ./service --scenario=steady; perf report --stdio | head -80 边界与误区 无符号或不可靠的栈展开会让火焰图失真。perf 权限、架构和事件支持不同，容器采样前要确认访问范围。 验证方式 同样场景至少重复多次，比较稳定区间；保留原始 perf.data 与符号，让他人能复查，而不是只留下截图。 小结 固定负载、编译选项和采样窗口，先用系统指标定位再用 profiler 解释热点。
背景 解析网络头时返回输入切片可以避免复制，但切片也会绑定输入缓冲区的生命周期。跨队列长期保存时，零拷贝可能变成资源占用。 核心判断 短生命周期解析返回借用切片，长期保存显式转 owned。 按原始协议长度检查边界，未找到分隔符不能无限积累缓冲。 同时测 CPU、分配次数和保留内存，而不是只统计 memcpy。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 fn parse_header(buf: &[u8]) -> Option<&[u8]> { let end = buf.iter().position(|&b| b == b'\n')?; Some(&buf[..end]) } 边界与误区 一个小切片若依赖大型 backing buffer，可能阻止整块缓冲释放。示例只定位换行，不执行编码校验，也不保证内容是合法完整协议头。 验证方式 覆盖无换行、空头、大包和跨读取边界，比较复制方案与借用方案的峰值内存；让生命周期约束在编译期保持可见。 小结 先建立拥有数据的正确性基线，再在测量证明有收益的局部引入切片和共享缓冲。
背景 CPU 利用率不高但请求很慢，可能是线程在等待 I/O，也可能是锁或远程依赖。iowait 只是入口，不是瓶颈的最终解释。 核心判断 把设备延迟、队列、吞吐与进程读写速率对齐到同一时间段。 结合 PSI 和 D 状态线程判断是否存在实际阻塞。 区分同步写、刷盘、随机读和后台维护流量。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 iostat -xz 1 5; pidstat -d -w 1 5; vmstat 1 5; cat /proc/pressure/io 边界与误区 sysstat 工具需要预先安装；PSI 支持取决于内核配置。单看 util 或 iowait 无法解释多队列设备的饱和程度。 验证方式 在已知顺序读和同步写场景下采样建立对照，再关联业务 p99。只有确认瓶颈来自存储路径，才讨论更换磁盘或增加并发。 小结 同时观察 PSI、磁盘延迟、队列深度、进程状态和请求耗时再定位瓶颈。
背景 两个线程更新不同计数器，逻辑上没有共享数据，却可能争用同一缓存行。伪共享是布局问题，不是原子变量失效。 核心判断 先确认热点来自并发写和缓存一致性开销。 按写入者划分数据，必要时使用每线程计数后聚合。 只有测量支持时才增加对齐或 padding。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 struct alignas(64) Counter { std::atomic<std::uint64_t> value{0}; }; struct Metrics { Counter accepted; Counter rejected; }; 边界与误区 64 字节只是示例假设，不是所有硬件的保证。过度 padding 会增加工作集，读多写少的数据可能因此更慢。 验证方式 固定线程数、CPU 亲和性和操作次数，对比吞吐及缓存相关事件。保留真实业务基准，不用单一空循环决定结构布局。 小结 高频并发写字段要避免伪共享，但任何 padding 都必须由 profile 证明收益。
为什么会积压 很多服务写了 worker pool，但上线后仍然： 高峰时队列暴涨 平均延迟还行，P99 很差 CPU 没打满却开始超时 这通常是“入队速率 > 出队速率”的背压问题。 基础模型 type Job struct { ID string } func startPool(ctx context.Context, n int, jobs <-chan Job) { for i := 0; i < n; i++ { go func() { for { select { case <-ctx.Done(): return case job, ok := <-jobs: if !ok { return } handle(job) } } }() } } 结构不复杂，难点在参数选择。 三个观测指标 吞吐：每秒处理多少请求 延迟：P50/P95/P99 队列深度：channel 长度趋势 如果队列长期接近上限，说明处理能力不足或外部依赖抖动。 调优顺序 固定业务流量，先找单 worker 处理能力 逐步增加 worker，观察 P99 与 CPU 变化 达到拐点后停止扩容，避免锁竞争和上下文切换过量 设置拒绝策略，不让队列无限增长 一个实用策略 快速失败：队列满时直接返回可重试错误 分级队列：高优先级任务单独通道 限时执行：每个任务绑定 context 超时 总结 worker pool 不是“越大越好”。并发数本质是资源预算，必须和外部依赖能力、延迟目标一起设计。