哎哟，这堆代码看着就头疼。
我以前在一家小公司做网页，老板非让我搞什么SEO优化，天天对着百度这那的规则瞎琢磨。
记得有年，公司接了个活儿，要做个在线教育平台，得把知道问答那套东西搬过去。
当时那帮小年轻天天对着这些脚本，愣是搞了半个多月。
最后上线了，效果嘛，也就那样。
不过话说回来，这玩意儿现在越来越复杂了，不像以前那么好搞了。

说白了，这个页面是百度知道的一个老版本界面，堆满了各种JS和资源加载代码。
其实很简单，就是个典型的Web应用加载流程，但细节挺坑的。

展开讲，首先看到这么多common-new:widget相关的模块，这表明是百度知道某个版本的后台框架；其次，require.resourceMap和pkg结构显示这是模块化打包的代码，去年我们跑的那个项目也用过类似结构，但3 000量级的页面用这种嵌套方式，加载时间会显著增加。
另外一点，__IKNOW_GLOBAL__这种全局变量存储状态，容易造成内存泄漏，去年我们处理过一次，涉及1 w+用户同时在线时卡顿问题。
还有个细节挺关键的，runCounter()函数会在1 5 秒后强制跳转，这个逻辑我一开始也以为是为了防爬，后来发现不对，其实是超时自动退出机制，挺反直觉的。

我一开始也以为BaiduHttps回调是做重定向，其实简单用正则替换http到https就够了，这种写法纯属形式主义。
等等，还有个事，countPosition()函数是计算悬浮框位置，但没看到实际调用，估计是某个废弃的功能残留。
这个点很多人没注意。

建议下次维护老代码时，先梳理清楚模块依赖关系，特别是这种深嵌套的加载方式，容易形成雪崩效应，其实就是前面一个小延迟把后面全拖垮了。