为什么我的 HTML 页面一直刷新？

上周有个客人问我为什么他们的HTML页面会一直刷新，我一看代码，果然是变量命名冲突导致的。
这事儿得从JavaScript的变量声明说起。

首先，JavaScript里用var声明的变量，如果是在全局作用域，比如直接在[xss_clean]标签里声明，其实它就相当于挂载到了全局对象上，在浏览器里这个全局对象就是window。
所以，如果写了个var location = _window.location;，其实相当于_window.location = _window.location;，这看起来像是赋值给自己，但浏览器会误以为你是在修改location对象，于是触发页面刷新。

其次，_window.location是浏览器提供的BOM对象，它用来获取或修改当前页面的URL。
当你直接对location赋值，哪怕赋值的是当前URL，浏览器也会认为你是想导航到新页面，所以就会重新加载页面，造成无限刷新。

解决这个问题的方法有几个：
1 . 可以用let或const来声明变量，它们不会像var那样挂载到全局对象上。
2 . 还可以用IIFE（立即调用函数表达式）来隔离作用域，这样变量就只在函数内部有效。
3 . 最简单的办法就是直接使用_window.location而不给它赋值，或者用不冲突的变量名。

关键知识点总结一下就是：

var的隐式全局挂载：顶层var声明的变量会成为window对象的属性。

location的特殊性：修改_window.location会触发页面导航。

作用域隔离：使用块级作用域或函数作用域可以避免全局污染。

建议学习一下JavaScript的作用域链和变量提升机制，还有var、let、const的区别。
遵守前端开发规范，避免使用保留字或BOM对象名作为变量名。
这样，页面无限刷新的问题就能解决了。
反正你看着办吧。
我还在想这个问题，也许还有其他更深入的解决方案呢。

如何获取页面加载完毕后的 HTML 代码？

这事儿我得跟你唠唠。
我当年搞前端的时候，也经常遇到这种需求。
获取页面加载完毕后的HTML代码，确实有几种方法。

我记着有年，在一个电商项目上，需求是得在用户提交订单前，抓取一下商品详情页的完整HTML，做个截图留底。
那时候页面加载还挺慢的，图片多，脚本也多。
直接用 DOMContentLoaded 事件就不行，人家图片还没加载完呢，这截图不全啊。
我就琢磨着，得等所有东西都加载完了。

于是我就用了 load 事件。
代码这么写：
javascript window.addEventListener('load', function() { const Code = document.documentElement.outerHTML; console.log(Code); });
效果挺好，等页面完全加载好了，再打印出HTML代码，截图也完整。
不过有时候，页面加载特别慢，用户等得着急。
那会儿有个项目，用户反馈说点开详情页，等半天没反应。
我一查，发现是某个大图片没加载完拖慢了节奏。
我就想，能不能先让用户点开，我稍微等一会儿再抓取？
就用了 setTimeout。
大概这么写：
javascript setTimeout(function() { const Code = document.documentElement.outerHTML; console.log(Code); }, 2 000); // 延迟2 秒执行
等两秒再抓，基本能满足需求。
当然，这得根据实际情况调整时间。
如果页面小，秒秒就加载完了，那这延迟就多余了。

还有种情况，就是页面加载速度还行，但里面有些内容是动态加的，比如评论区，用户评论后才会加载出来。
那 load 事件就不管用了，因为整体页面早加载完了，但内容还没呢。
这时候我就得用点别的招。
比如监听某个评论加载完成的事件，或者用AJAX请求看看内容是不是出来了，出来了再抓HTML。

我记得有一次，在一个论坛项目上，用户发帖后，帖子内容是异步加载的。
那我就得在发帖成功后的回调里抓取HTML。
代码大概是这样：
javascript // 发帖成功后调用的函数 function onPostSuccess() { // 假设帖子内容加载在一个id为'post-content'的元素里 const postContent = document.getElementById('post-content'); if (postContent) { const Code = postContent[xss_clean]; console.log(Code); } }
这样就能确保动态内容加载出来了再抓取。

哦对了，还有个坑，就是跨域问题。
我以前在一个测试项目中，想抓取一个第三方网站的HTML，结果直接用 document.documentElement.outerHTML 就报错了，说不是同源。
那时候我挺蒙的，一查才发现是浏览器安全策略。
后来我就用了服务器端代理，把第三方网站的页面内容先抓取下来，再返回给前端。
或者对方支持CORS，加上相关头，也能解决。

总的来说，获取页面加载完毕后的HTML代码，得根据具体情况选方法。
要是页面加载慢，就用 load 事件；要是页面加载快但内容动态加载，就用回调或者监听事件；要是跨域，就得想办法绕过同源策略。
我当年踩的坑，就是没考虑到动态内容和跨域，差点就项目延期了。

为什么HTML在线页面加载慢_HTML在线页面加载慢问题排查与加速方案

哈喽啊！你这长篇大论看着挺专业，但说实话有点像在念论文... 我自己搞网站的时候，其实没这么多条条框框，都是踩坑总结出来的经验。
你想知道HTML页面加载慢咋办，我给你唠唠我碰到的具体情况哈。

比如说啊，2 02 3 年我在上海帮一个朋友做电商网站，那页面加载速度真是慢得要命。
打开开发者工具一看，好家伙，TTFB（首字节时间）直接飙到8 00ms以上。
你想想，用户等了那么久，能不崩溃吗？后来我才知道啊，主要问题出在后端。
他们那个查询数据库的SQL语句写得特别烂，每次用户访问都要去数据库捞半天数据。
而且服务器配置也低，就一台普通的服务器，CPU老卡。

我给他们整了几招： 1 . 把那些复杂的SQL语句改掉了，能合并的查询都合并了。
2 . 上了Redis缓存，把一些不常变动的数据存起来。
3 . 最后实在不行，把服务器升级了，换了台性能更好的。

你看，这就是典型的服务器响应差的问题。
还有啊，他们那些静态资源，JS、CSS、图片啥的，都没用CDN。
我后来给他们整了阿里云CDN，把东西分发到全球节点，结果用户从美国访问都感觉快多了。
这个真的太重要了，尤其是现在大家都用手机刷手机，网速时好时坏的，CDN必不可少。

再说说前端优化。
我自己做项目的时候，最头疼的就是图片太多。
之前有个新闻网站，我优化前它首页图片加载得像乌龟爬。
后来我给他们用了懒加载，非首屏的图片都加了loading="lazy"属性，结果第一次加载速度直接快了5 0%。
还有啊，他们CSS文件动不动就几百KB，我用了CSSNano压缩了一下，直接瘦了三分之一。
JS也是一样，用了Terser压缩，体积小了一半多。

合并雪碧图这个我也常用。
之前有个项目里面小图标一大堆，单独请求太慢了，我给他们合并成一个雪碧图，用CSS定位显示需要的那一小块。
HTTP请求数少了，加载自然就快了。
还有内联关键CSS，把首屏必须用的CSS直接写在HTML里，避免额外请求。

HTML结构这块也很有讲究。
之前有个企业官网，DOM嵌套太深了，我一看就皱眉，里面好多不必要的div。
后来我改用Flex布局，DOM层级立马降下来了。
浏览器解析速度都快了。
还有啊，script标签放位置很重要，我以前总把JS放在body最后面，结果发现页面渲染卡在那儿等脚本加载。
后来我改用defer属性，效果立竿见影。

缓存这块我也踩过坑。
之前有个网站，用户每次访问都要重新加载资源，特别浪费流量。
后来我给他们配置了HTTP缓存头，Cache-Control设得长一点，ETag也用上。
结果用户第二次访问，速度提升明显。
ServiceWorker我也用过，给个PWA项目整了缓存，用户离线都能看页面，体验太好了。

你看，这些方法都是实打实搞出来的，不是啥理论。
你要是页面加载慢，建议先拿开发者工具看看瓶颈在哪。
是TTFB长？还是资源体积大？或者是DOM解析慢？一个个定位解决了，速度肯定上去了。
反正你看着办吧，我这都是踩坑总结的，希望能帮到你。

页面刷新时onload事件如何执行？

哎，你这长篇大论的，我看得头都大了... 行吧，我给你捋捋最关键的部分。

你说的这个 onload 事件，说实话，我之前用得挺多的。
最明显的感觉就是，每次你刷新一个页面，特别是那种加载图片特别多的，你会发现浏览器会卡一下，等所有东西都下来完了，那个 onload 事件才触发。

比如说啊，2 02 3 年我在上海搞个测试，一个H5 页面，里面挂了十几张高清图。
你用 _window.onload 把个弹窗写在里面，第一次打开可能还行，但如果你刷新一下，浏览器得先去把那十几张图都拉下来，等全部加载完毕，弹窗才弹出来。
这中间的等待感，用户肯定受不了。

而且啊，你说的这个 onload 和 DOMContentLoaded 可真是个头疼的事儿。
DOMContentLoaded 是啥？就是DOM树建好了就行，不管你图片、CSS啥的。
我之前做项目，有时候想等DOM一准备好就执行个脚本，用 DOMContentLoaded 比较快。
但 onload 就得等所有东西都下来了，慢得多。

还有啊，你说的绑定问题我也踩过坑。
以前老是用 _window.onload = function() { ... } 这种写法，后来发现，如果你刷新页面，绑定了一次又一次，后面的就给前面的盖过去了。
后来改用 addEventListener 就好多了，window.addEventListener('load', function() { ... })，这样每次刷新都能触发所有绑定的。

优化这块，你说的也挺好。
少加载点资源肯定快，CSS JS合并一下，该用 async / defer 的都用上。
还有，如果真的非要用 onload，那你就得考虑用户体验，别干啥重要的操作都压在 onload 里头，用户等得太久会跑的。

总的来说吧，onload 事件是肯定有用的，特别是需要等整个页面铺开才干的活儿。
但用的时候得注意，别把它当万能钥匙，有时候用 DOMContentLoaded 或者观察者啥的更合适。
你看着办吧。