我不是全职 Javascript 开发人员。我们有一个网络应用程序，其中一部分是将一个小的信息小部件写入另一个域。这实际上只是一个 html 表，其中写入了一些值。在过去的 8 年里，我不得不这样做几次，最后我总是通过一个脚本来完成它，而 document.write 不在表格中。
例如:
document.write('<table border="1"><tr><td>here is some content</td></tr></table>');
在 theirdomain.com 上
<body>
....
<script src='http://ourdomain.com/arc/v1/api/inventory/1' type='text/javascript'></script>
.....
</body>
我一直认为这有点丑陋，但效果很好，而且我们始终可以控制内容(或者受信任的代表可以控制您当前的库存等)。所以出现了另一个这样的项目，我使用 document.write 在大约 5 分钟内完成了编码。其他人认为这太丑陋了，但我不明白问题出在哪里。关于小部件方面，我也完成了 iframe 和 jsonp 实现，但 iframe 往往不能很好地与其他站点的 css 配合使用，而 jsonp 往往太多了。我缺少一些安全元素吗？或者我在做什么好吗？反对使用这种技术的最有力论据是什么？有没有我没有得到的最佳实践？
最佳答案
老实说，我真的看不出有什么问题。是的，document.write 非常老派，但它很简单并且得到普遍支持；您可以相信它在每个浏览器中都可以正常工作。
对于您的应用程序(写出包含一些数据的 HTML 表格)，我认为没有必要使用更复杂的解决方案如果您愿意假设一些小风险。如果您不使用 jQuery(等)，处理跨浏览器正常工作的 DOM 突变并不是一件容易的事情。
document.write的风险:
您的脚本必须同步加载。这意味着一个普通的内联脚本标签(就像你已经在使用的一样)。但是，如果有人变得聪明并添加了
asyncordeferattributes到您的脚本标签(或执行一些 fancy 操作，例如将动态创建的script元素附加到head)，您的脚本将被异步加载。这意味着当您的脚本最终加载并调用
write时, 主文档可能已经完成加载并且文档被“关闭”。打电话write在关闭的文档上隐式调用open，这完全清除 DOM – 这在本质上与清除页面并从头开始相同。你不想要那个。因为您的脚本是同步加载的，所以您将第三方页面置于您 服务器的支配之下。如果您的服务器出现故障或过载并响应缓慢，则包含您的脚本标记的每个页面都无法完成加载，直到您的服务器响应或浏览器超时请求。
将您的小部件放在他们网站上的人不会高兴。
如果您对自己的正常运行时间有信心，那么就真的没有理由改变您正在做的事情。
另一种方法是异步加载脚本并将表格插入 DOM 中的正确位置。这意味着第三方必须同时插入一个脚本片段(<script async src="..."> 或使用动态脚本标签插入技巧。他们还需要创建一个特殊的 <div id="tablegoeshere"> 供您放入表格。
关于javascript - 在远程加载的 javascript 中使用 document.write 写出内容——为什么是个坏主意？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21173780/