在一次发布中，后台项目新增了 Excel 导出功能。功能只出现在订单列表页，开发者本地验证导出正常后提交上线。发布完成后首页没有报错，接口响应也不算慢。但使用者打开程序时白屏时间明显增加导致业务指标下降和使用者流失。

一、本次问题：白屏时间变长

使用者在登录或刷新首页时会看到一个长时间的白屏，这让他们怀疑是网络延迟或接口太慢。只是浏览器网络面板显示首页接口耗时仅数十毫秒，而实际页面渲染被拉得很久。

1️⃣ 开发者常见误区

• 直接把注意力放在接口调整上；
• 盲目引入路由懒加载或压缩图片；
• 不确认哪个阶段真正占用了大部分时间。

这些操作往往会同时修改多个地方。却无法确定哪项改动真正缩短了首屏时间，从而导致效率低下。

二、一切从资源下载开始拆解

浏览器渲染流程可简化为：

请求 HTML → 下载 CSS 和 JavaScript → 解析并执行入口脚本 → 创建应用和路由 → 请求首页数据 → 渲染首屏内容

任何一步变慢都可能导致整个白屏等待。下面用表格来快速定位：

1️⃣ 浏览器网络记录示例

index.html KB ms
index-a81f3.js MB s
user-profile KB ms
dashboard-summary KB ms
...

其中主脚本 index-a81f3.js 的下载时间远高于两个首页接口。

三、“建立产物”为何比源码文件更值得先看？

新增导出功能时只改了几十行代码：

import * as XLSX from 'xlsx'
export function exportOrders {
const sheet = XLSX.utils.jsontosheet
const book = XLSX.utils.booknew
XLSX.utils.bookappend_sheet
XLSX.writeFile
}

虽然源码体积微小。却因为被全局插件引用而被打进入口包，导致最终产物增大。建立完毕后应查看产物大小，例如：

dist/assets/index-a81f3.js,kB │ gzip: kB
dist/assets/vendor-f3c2.js。kB │ gzip: kB
dist/assets/order-91ab.js,kB │ gzip: kB
...

如果有分析插件，可直接查看依赖树；若无，可通过两次建立对比快速定位增长点。其实，

"Git 对比法"

="" 修改前="">
pnpm build

// 修改后 git checkout pnpm build

对比相同命令下生成文件大小差异。即可判断是否因某个模块被错误地引入到入口。

"主要结论"

导出依赖意外进入初始建立链路是常见误区：   静态导入会参与当前模块的依赖分析；若此模块被入口同步引入，则整个包都会变大。)

"四、“静态全局导入”的陷阱与维护成本"

项目将导出工具注册为全局插件：

="" p="" plugins="" src="" xlsx="" {="" }="">

并在入口同步加载：