这是典型的后端没响应或网络中断，不是前端代码问题；需检查服务存活、端口连通性、代理设置及浏览器兼容性，而非修改JS代码。
Chrome 控制台报 net::ERR_CONNECTION_TIMED_OUT 怎么办
这是典型的后端没响应或网络中断，不是前端代码问题。先别急着改 js，重点查服务是否存活、端口是否通、代理是否拦截。
常见错误现象：页面卡在 100%，Network 面板里对应请求状态一直是 pending，几秒后变成 net::ERR_CONNECTION_TIMED_OUT；但其他接口（比如登录）能正常走通。
- 用
curl -v http://your-api-domain/endpoint直连后端，看是否返回响应 —— 如果也超时，说明是服务层或网络策略问题 - 检查浏览器是否开了代理（尤其是系统级代理或公司 PAC），关掉再试；Mac 用户注意「网络设置 → 高级 → 代理」里有没有勾选自动代理配置
- 如果是本地开发环境，确认后端进程没崩溃：
lsof -i :3000（Linux/macOS）或netstat -ano | findstr :3000（Windows）查端口占用
Firefox 显示 ImportMap is not defined 却卡在 100%
这说明浏览器不支持 importmap，但 HTML 里写了，导致解析阻塞后续资源加载。不是卡住，是直接失败了，只是 UI 没反馈。
使用场景：用 Vite 或 esbuild 开发时启用了 import map 功能，但忘了兼容老浏览器或未开启 polyfill。
- 检查 HTML 中是否包含
<script type="importmap"></script>块；如果目标用户含 Firefox 110 以下或 Safari 16.4 以下版本，必须移除或降级为传统script src引入 - Vite 用户可在
vite.config.ts中设build.target: 'es2015'并禁用build.rollupOptions.output.manualChunks的 importmap 输出 - 不要依赖控制台“没有报错”就认为没问题 —— Firefox 对 importmap 的静默失败很常见，建议用
if ('importMap' in document) { ... }做运行时兜底
DevTools Network 面板显示 stalled 超过 30 秒
这不是代码 bug，是浏览器并发限制或 DNS 缓存异常。Chrome 默认对同一域名最多 6 个 TCP 连接，打满就会 stalled。
性能影响明显：即使后端毫秒级响应，前端也可能因连接排队卡住十几秒。
- 打开 DevTools → Network → 右键表头 → 勾选
Connection ID，观察是否大量请求共用同一个 ID —— 是则确认为连接复用瓶颈 - 临时解决：把静态资源（如
/assets/）换到子域名（static.example.com），绕开同源并发限制 - 长期方案：服务端启用 HTTP/2（必须 HTTPS），它允许多路复用，
stalled会大幅减少；Nginx 配置里确认有http2 on; - 别信“清缓存就能好”——DNS 缓存和 TLS 握手缓存才是元凶，试试
chrome://net-internals/#dns清空 DNS 缓存
localStorage.setItem 后页面卡死，控制台无报错
极大概率是监听了 storage 事件的脚本里触发了无限循环，比如 A 存值 → B 监听到 → B 又存值 → A 再监听……
容易踩的坑：很多人以为 storage 事件只在其他 tab 触发，其实当前页调用 setItem 不会触发自身监听，但若用了 redux-persist 或自定义同步逻辑，就可能绕过这个限制。
- 搜索项目中所有
window.addEventListener('storage',，检查回调函数里是否调用了任何写 storage 或触发重渲染的操作 - 临时加防护：在 storage 回调开头加
if (event.key === 'xxx' && event.url === window.location.href) return;，避免本页误响应 - Chrome 120+ 已限制 storage 事件最大调用栈深度，但旧版仍会卡死；Safari 更激进，可能直接丢弃后续事件
