你知道你可以让服务器使用.htaccess将HTML页面解析为PHP（在HTML文档中执行PHP代码）吗？
好吧，有些人说这样做很糟糕。为什么？
有些人还说它会在您的应用程序中打开一个安全漏洞。如何？
在文档到达浏览器之前，源代码仍然会被删除，因此不可能是未经授权访问源代码的情况，对吧？
让我从一个小故事开始：当我还是 Linux 发行版供应商的安全联系人时，PHP 安全团队恳求 Linux 供应商停止调用解释器崩溃的安全漏洞，即使 PHP 解释器在 Web 服务器内部运行（例如，在 Apache 上mod_php）。（当时，每周大约有一次口译员崩溃。
他们花了一点时间才真正说服我们，提供正在运行的PHP代码的人是完全受信任的，任何试图控制脚本可以从解释器做什么的尝试都是错误的 - 如果有人想出如何崩溃解释器以绕过它试图施加的限制（例如整个愚蠢的安全模式堆废话）， 这不是一个安全漏洞，因为脚本的安全执行不是PHP解释器的目标 - 它从来没有，也永远不会是。
实际上，我对讨论的最终结果非常满意 - 它清楚地定义了PHP的安全目标：您应该只允许执行100%完全信任的PHP代码。如果您不信任它，则不会运行它。就是这么简单。
解释器可用的任何操作系统资源都是可用的和公平的游戏，无论脚本是利用解释器中的错误还是只是做了一些意外的事情。
因此，请不要允许在您的Web服务器上下文中执行随机代码，除非这是您真正想要的。
请使用最小特权原则来指导每个程序可用的资源。
考虑使用强制访问控制工具（如 AppArmor、SELinux、TOMOYO 或 SMACK）来进一步限制程序可以做什么和不能做什么。我从 2001 年左右就开始从事 AppArmor 项目，并且相当有信心，只要一天的努力，大多数系统管理员就可以使用 AppArmor 以有意义的方式增强他们的站点安全性。请评估几个选项，因为不同的工具是围绕不同的安全模型设计的 - 一个或另一个可能更适合。
但是，无论您做什么，请不要以不必要地打开服务器以通过额外媒介进行攻击的方式运行您的服务器。
主要问题是，如果你把你的代码移动到另一个服务器，或者让别人处理你的代码，服务器设置，或者你的html页面.htaccess文件可能会停止被PHP解释器解析。
在这种情况下，PHP 代码将提供给浏览器。
存在一个安全漏洞，即如果您这样做，HTML 文件实际上是 PHP 文件，因此上传它们应该像上传 PHP 文件一样认真对待。 通常人们不认为上传HTML文件有什么大不了的，正是因为他们不希望它们被设置为解析为PHP（所以你公司的其他人可能会无意中打开一个安全漏洞）。[PaulP.R.O. 的回答指出，安全问题也可能在相反的方向出现 - 因为 PHP 稍后被错误地删除此设置时被误认为是 HTML。
还有一个性能问题，因为每个HTML文件都必须通过PHP解析器运行（即使它碰巧不包含PHP）。
由于速度和组织原因，将HTML解析为PHP是不好的。
- 解析为 PHP 的 HTML 文件在技术上加载速度较慢，因为您正在调用 PHP 引擎。
- 但大多数情况下，这对组织目的不利：随着项目的扩展，想象一下在HTML文件中寻找嵌入式PHP代码。 浏览项目时，文件扩展名应该是该文件用途的真正指标。 如果表单提交到"登录.php"，您可以合理地确定它包含服务器代码。 但是"登录.html"可能只是另一个HTML页面。
关于您评论的其余部分，我不确定安全性方面，但我认为混淆您的 HTML 和 PHP 输出可能会导致未被注意到的 XSS 漏洞？ 不过，在这方面不是专家。
这对速度不利，如果PHP解释器由于某种原因不起作用，PHP代码将显示在页面源代码中。例如，如果您在PHP代码中有数据库用户名和密码，则任何人都可以轻松连接和访问您的数据库。
正如zed所说，由于组织原因，这是不好的。您需要更新站点上的所有文件以进行简单的更改，而不是更新一个文件。
允许服务器将 HTML 文件解析为 PHP 表明您没有使用专有的应用程序设计模式。也就是说，您正在开辟自己的道路，而不是按照推荐的方式做事。像MVC（将关注点分开）这样的设计存在是有原因的。
允许直接调用任意文档的一个问题是丢失了"前端控制器"（通常是索引.php），这有助于收紧进入应用程序的门口数量。
你可以有很多进入你的应用程序的路径，但你的设计中必须涵盖更多可能的攻击路径。