中后台的性能问题往往不在渲染，而在「一次性要了太多数据」。
这个页面每天被内部运营打开数百次，每次等待接近四秒。用户抱怨的是「卡」，而真正的问题是一口气加载了 47 个字段、8 个字典接口和全部导出能力。
火焰图显示渲染只占 0.4s，剩下 3.4s 全部花在等待与序列化上：列表接口返回全量字段，其中大部分在列表页根本不展示。
换句话说，这不是前端问题，而是一次「接口为了通用而牺牲了专用」的代价，只是最后由浏览器买单。
47 个字段里列表只用到 11 个，其余是详情与导出用的，序列化与传输成本却全额承担。
8 个字典接口逐个请求，每个 80–150ms，累加就是 1 秒以上。
导出模块在页面初始化时就加载，而绝大多数会话根本不会用到它。
第二条经验是：中后台用户对动画不敏感，但对等待敏感，所以优先砍等待而不是优化交互。第三条是：把接口设计纳入性能讨论，否则前端优化很快会碰到天花板。
中后台的性能预算应该按「每秒的操作次数」来算，而不是按页面数量。一个每天被打开 300 次的页面，慢 1 秒就是每天多消耗 5 分钟人力。
这次改动没有引入任何新技术，全是删减与合并。多数中后台的性能问题都是这样——不是做得多，而是要得太多。
告诉我们所在行业与业务阶段，我们提供对应的交付路径与周期参考。
