在你回复之前，是的，我已经阅读了这篇文章。
我的问题的不同之处在于，我不是在寻找最佳实践或互联网速度考虑因素，而是在崩溃之前可以处理的实际最大浏览器（或每个浏览器，如果您希望或必须具体）可以处理，以及 php 引擎在崩溃之前可以处理多大的文件。
原因是我正在为我工作的公司构建一个在线工作申请，并且我有很多必要的 JavaScript 验证（不过，我把我能做的放在外部 js 文件中）以防止垃圾邮件和滥用。我还让 PHP 与 JavaScript 交织在一起，以测试 PHP 是否处于活动状态，如果没有，则返回到 JavaScript 函数。我也有 jQuery、MooTools 等等……更不用说所有必需的问题、文本框、下拉列表、单选按钮、复选框和文本区域了。
问题是我只完成了在线申请的一部分，我的文件已经是 32 KB。考虑到我已经完成的工作量以及剩下的工作量，我可以看到这个 html/php (.php) 文件轻松达到 200KB+
所以我需要知道典型的 HTML 浏览器和服务器端 PHP 引擎的真正最大限制。
提前致谢，
-詹姆士
I cannot foresee a modern browser or server 'choking' on 200KB of HTML or PHP respectively. Large PHP apps verge into the Megabytes and I've seen pages with Megabytes of markup.
The issue here is more code organization. If you're putting that much code in a single file, something is probably wrong. Consider splitting up your code using something as primitive as PHP's include() function or something as comparatively revolutionary as writing your code on one of the many MVC frameworks that are out there.
这完全取决于浏览该站点的计算机。在相当现代的 PC 上，您应该能够在浏览器出现问题之前让您的脚本吐出几兆字节，而这些通常只是渲染页面的延迟。
在之前的工作中，我正在使用 WinXP 和 1.5GB 内存的单核 1.lownumber GHz Celeron 机器[比你想象的更近]。我正在实施一个垃圾邮件过滤产品，该产品并非设计用于处理 10,000 多个域，因此会吐出带有超过 8MB 标记的页面。浏览器很好地收到了页面，没有抛出错误，但需要几分钟才能显示页面。
大约一年后，当我得到一台新的双核 Win7 机器时，延迟几乎没有引起注意。
也就是说，每页 400KB 的数据并不可怕，但也不是那么好。我会更关心放置在服务器上以生成那么多标记的负载，以及放置在网络上以传递它的负载。您应该考虑减少随每个请求发送的数据量的方法 [分页，AJAX] 并重新评估用户在每个请求中真正需要查看多少数据。
-> 这是重要的一点。
不要依赖 Javascript 来防止垃圾邮件/滥用/无效数据等。它只使人们能够提供更愉快的用户体验。而已。
使用 PHP 脚本等确保适当的数据存储在服务器上。
那是你的资产，人们也可以对你关闭/解雇 JavaScript。
-> 您的服务器端对点击次数有争议。只需监控流量