打开360浏览器卡住

今天突然发生的，用AI弄了很久也没办法，最后说是可能是因为更新了新版的问题
下面是AI的一些对话，太长了就不全部弄上来了。打开就像图片一样卡5秒左右。
重要结果——代理的锅**被排除了**,同时卡顿点定位得更准了。代理已恢复原样(`ProxyEnable=1`)。

**A/B 对照(两次都是同一段卡顿)**
- 有代理:进程起来后 CPU 冻在 `0.81`,`1.6s → 5.3s` 卡约 3.7 秒,`6.5s` 解冻。
- 无代理:进程起来后 CPU 冻在 `0.86`,`0.6s → 5.8s` 卡约 **5.2 秒**,`6.2s` 解冻。

**这说明什么**
关掉代理**一点没变好,甚至更长**。所以卡顿**不是代理链路**造成的。两次共同特征极其明确:
- 进程数卡在 `4` 个不增长
- CPU **完全冻结不动**(0.81 / 0.86,一动不动)
- 磁盘也不动(上一次测过 磁盘队列=0)
- 卡到第 6 秒左右,进程数**突然从 4 跳到 9-10**,CPU 才开始爬升

**CPU 不动 + 磁盘不动 + 进程不增长,持续到某个固定时刻才解冻** —— 这不是在算、不是在读盘、不是在等你的代理。这是主进程起来后**卡在一个固定的等待/超时上,等满约 5 秒后才去拉起子进程(渲染进程),窗口才真正可用**。

**最可能的元凶(按嫌疑排序)**
1. 360 自己的**启动时联网检查**:账号云同步、安全组件校验、升级检查、导航/推荐预拉取。这些常带一个几秒的硬超时,网络不畅时就卡满超时才放行——非常符合CPU不动、等固定时长的特征。
2. 某个**扩展的 service worker 初始化**握着启动流程(之前看到 Service Worker 数据有 460MB)。
3. 证书吊销检查(CRL/OCSP)首次联网超时。

代理排除后,`1` 号(360启动联网检查)嫌疑最大。

**下一步验证(帮你二选一)**
- 方案A:我做**无痕模式**冷启动对照(`--incognito`,不加载扩展、不做账号同步)。如果无痕秒开不卡 → 锁定是扩展或账号同步。
- 方案B:我用系统的进程监控抓那 5 秒里 `360se.exe` 主线程具体**卡在哪个等待**(等网络句柄还是等命名管道/事件)。

想让我先跑哪个?我建议**先跑 A(无痕对照)**,最快能区分是360自身还是扩展。要我直接测吗?
这次对照测试是决定性的。我把结论和数据一起摆出来。

**关键对照:Chrome vs 360**
- **Chrome**(全新配置、同一台机、同样的网络/代理/DNS):`1.3秒`进程数就冲到 9 个,**完全没有那段冻结**,正常。
- **360**(所有情况):进程数都卡在 `4` 个,冻结约 4-5 秒,到第 6 秒才涨到 9-10。

同一台电脑、同样的网络环境,**Chrome 秒开、360 卡 5 秒**。这说明卡顿是 **360 浏览器自身启动逻辑**的问题,不是系统级(不是网络、不是磁盘、不是 DNS、不是代理)。

**这一轮排除的(都有数据支撑)**
- WPAD 自动检测:关掉后**照样卡**(解冻仍在 6.2 秒)→ 排除。
- 用户配置/扩展/历史:用**全新空白配置**启动 360,**照样卡**(卡到 6 秒)→ 排除,不是你的配置或收藏或缓存的问题。
- 扩展/脚本:无痕模式**照样卡** → 已排除。
- 网络/代理/磁盘/F盘:多轮实测全排除。

**现在能确定的结论**
`360se.exe` 主进程启动后,会**固定地冻结约 5 秒**(CPU、磁盘、网络全静止),然后才拉起渲染子进程、窗口才可用。这是 360 主程序内部**卡在某个固定超时/等待**上——最可能是它自带的某个后台组件(账号/云控/安全守护/升级检查)在初始化时等一个响应等满超时。全新配置都复现,说明是**程序本身**,不是数据。

**一个仍待确认的疑点**
`se.360.cn` 用主 DNS `192.168.2.2` 解析,**第一次要 605ms**(后面缓存了才 2ms)。360 启动时可能要连它自己的多个服务器,首次逐个解析+连接如果部分超时,累积起来就是这 5 秒。这也和F盘坏那天开始能对上——那次网络/路由变动影响了对 360 服务器的连通性。

**给你的实际解决方案(按性价比)**
- **首选:换掉 360**。同机 Chrome 秒开,而这卡顿是 360 自身逻辑,除非它自己修,否则治标难治本。你可以直接用 Chrome,或换 Edge。
- 如果一定要用 360:
  - 设置里关掉**账号自动登录/云同步、开机自启、升级检查、安全防护**这些启动时联网的组件,能减少启动等待的组件数量。
  - 或用 hosts 把 360 的启动检查域名(如 `se.360.cn` 等)指到 `127.0.0.1`,让它秒失败而不是等超时——但这可能影响部分功能,属折中手段。

要不要我帮你**抓一次 360 启动那 5 秒里它到底在连哪些 360 域名/等哪个**(用系统级连接快照),把那个具体的超时目标揪出来?揪出来后就能用 hosts 精准干掉它,让 360 也能秒开。这是唯一还能让 360 本身变快的路径。
全部测完了,代理和 WPAD 都已恢复原始状态,临时文件也清理了。我把最终定位讲清楚。

**卡顿那几秒进程在干什么(最硬的证据)**
在冻结的第 2.2 秒抓主进程线程状态:
- 主进程 57 个线程,大部分是 `UserRequest`(37个)和 `EventPairLow`(15个)等待——**没有一个线程在等网络、等磁盘**。
- 句柄数、内存、IO 计数在冻结期间**完全不增长**(828 句柄纹丝不动)。
- 冻结期间网络连接:只有到 `127.0.0.1:10808`(代理)一条,而且是**第 5.4 秒才出现**的——也就是网络是解冻之后才发生的,不是卡顿原因。

**这说明卡顿的本质**
主进程(browser 进程)起来后,**gpu-process 和 utility 子进程已经拉起(n=4)**,但**渲染进程(renderer)迟迟不拉起**,主进程在一个内部事件上干等约 5 秒。CPU/磁盘/网络/句柄全静止 = 它在**等一个进程间同步事件(EventPair)超时**,而不是在算、读盘或联网。

**决定性对照(全部指向 360 自身)**
- Chrome 同机同环境:`1.3秒`就拉起全部子进程,**完全不卡**。
- 360 全新空白配置:照样卡 → 不是你的数据/配置。
- 360 无痕模式:照样卡 → 不是扩展/脚本。
- 关代理、关 WPAD:照样卡 → 不是网络设置。
- 保留后台守护服务再启动主程序:**照样卡** → 不是守护服务冷启动。

**结论**
这是 **360 安全浏览器 `16.1.6116.64` 这个版本自身的启动缺陷**:主进程启动时卡在一个内部同步等待上,固定耗时约 5 秒才拉起渲染进程、显示页面。和你的电脑、网络、F盘、磁盘、扩展、配置**都无关**——是软件本身的问题。另外我注意到装了**两个版本**(`16.0.6047.0` 和 `16.1.6116.64` 并存),新版是今天(8/22)更新的,**你的卡顿很可能就是这次版本更新引入的**,时间点跟最近开始卡高度吻合。

**建议(按推荐度)**
- 首选换浏览器:同机 Chrome 秒开,直接用 Chrome 或 Edge 最省心。
- 想继续用 360,先试**回退版本**:今天更新到 `16.1.6116.64` 后才卡,可以在 360 里关掉自动升级,或卸载重装一个稳定旧版(旧版 `16.0.6047.0` 的目录还在)。
- 或者**彻底卸载重装** 360:清掉多版本残留,用干净安装,有时能消除这种升级后遗留的启动卡死。
- 反馈给 360:这是它的启动 bug,普通设置调不好。

**我做过的改动汇总(都已保留或恢复)**
- 首页:`hao.360.com` → `https://www.baidu.com/`(保留,备份在 `Preferences.bak_startupfix`)。
- 代理 `ProxyEnable`、WPAD 设置:测试后**已恢复原样**。
- v2rayN 的 DNS(之前那次):`doh.pub`,保留。

要不要我帮你**回退到旧版 `16.0.6047.0` 并关掉自动升级**,验证一下旧版是不是不卡?如果旧版秒开,就说明是新版的问题,你也能继续用 360。

您好，查看到您提供截图，不要使用http://baidu.com为主页，请使用https://www.baidu.com 这个网址再看看。