考虑到 document.write() 的负面影响，为什么大多数跟踪/营销标签都是使用 document.write() 编写的？
我已经考虑了很多，我想出的唯一值得尊重的想法是，通过在客户端编写它，我们可以保证浏览器不会尝试缓存资源。是这样吗？还有其他想法吗？
【问题讨论】：
标签： javascript html
这绝对是丑陋的，但它是关于最久经沙场、最愚蠢、最防白痴的方法。 “在此处将内容写入页面”的范例几乎没有令人惊讶的余地，并且该实现至少可以可靠地运行到 v3 浏览器，可能更早。
[edit]“v3”浏览器，不像 Firefox 3 那样，而是像 Netscape 3 那样。如果 Netscape 今天仍然存在，我想它现在应该是版本 11。
【讨论】：
使用 document.write 插入页面的脚本不会阻止其他脚本的执行，因此在将广告的外部资源插入页面时不会影响页面加载速度。更多信息在这里：http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/
【讨论】：
我没有看到这种方法在浏览器缓存方面有任何保证......？例如，如果它请求一张图片，浏览器可能仍会选择从缓存中提供该图片，无论该请求是来自原始源中的 IMG 标记，还是来自document.write 编写的 IMG 标记。
我最好的猜测是他们希望脚本是独立的并且易于部署。很多时候（并且出于显而易见的原因）引用的脚本（例如图像指向的 URL）是不同的，这取决于当前页面是否通过安全的 HTTPS 连接加载。如果当前页面是https页面，则加载https://omniture.com/xxx，否则加载http://omniture.com/yyy。这在 javascript 中很容易实现，但您不能在 HTML 中对其进行硬编码。给定任何服务器端语言，它同样容易实现，这将是更可取的，但我认为他们不想说“继续以你喜欢的任何方式实现这个功能”，而是他们想要提供一个尽可能好用的解决方案，不受环境影响，并且依赖尽可能少。
【讨论】：
它与缓存无关。它与脚本提供者不知道脚本放置在文档中的哪个位置有关。脚本提供者不能只做document.getElementsByTagName("script") 并在第一个具有匹配 URI 的脚本标记之后插入 HTML，因为它不知道 URI 是否包含哈希 (http://example.com/blah.js#foo) 或直接托管在第一方服务器以减少 DNS 请求。有一种解决方法，但它涉及使用在捕获的错误中暴露的脚本文件名中的黑魔法。这种魔法的实现可以在my implementation of document.write for asynchronous scripts 中找到。 (<script async>)
【讨论】：