PHP文件显示源码是因为未经服务器解析执行，须部署于XAMPP等本地环境并通过http://localhost访问；敏感文件应置于Web根目录外，并配置.htaccess或Nginx禁止直接访问；混淆无效，应通过前后端分离、API校验与权限控制保障安全。

直接打开 PHP 文件时看到源码，说明服务器没运行它，而是当纯文本返回了——这不是代码“没隐藏”，是根本没执行。PHP 代码本身不需要、也不该靠“混淆”来隐藏，真正要解决的是：让 PHP 文件只在服务器上解析执行，不被浏览器直接读取源码。

确保 PHP 文件由 Web 服务器解析

这是最根本的前提。如果双击 .php 文件或用浏览器直接打开本地 file:// 路径，肯定看到明文代码——PHP 不是前端语言，不能像 HTML 那样直接运行。

• 把文件放到支持 PHP 的本地环境里（如 XAMPP、WAMP、MAMP 或 Docker 中的 Apache/Nginx + PHP）
• 通过 http://localhost/xxx.php 访问，而不是 file:///.../xxx.php
• 检查服务器是否启用 PHP 模块（例如 Apache 的 libphp.so 或 PHP-FPM 是否正常工作）

禁止 Web 目录被直接浏览和下载

即使 PHP 正常执行，也要防用户绕过入口、直接请求敏感文件（如 config.php、functions.php）。

• 把非入口文件（如数据库配置、工具类）放在 Web 根目录之外（例如 /var/www/app/ 和 /var/www/public/，只把 public 设为网站根目录）
• 在 Apache 中用 .htaccess 禁止访问敏感后缀：
  Require all denied
• Nginx 中对应配置：
  location ~ \.(php|inc|conf|ini|log|sh)$ { deny all; }

混淆 ≠ 安全：别迷信“PHP 加密”工具

网上很多“PHP 混淆加密”工具（如 Base64 编码、字符串拼接、eval 动态执行），实际作用极小：

• 它们无法阻止有权限访问服务器的人查看原始代码（比如运维、合作开发者）
• 绝大多数混淆可被一键还原（在线解密工具秒破），反而影响调试和性能
• 过度混淆可能触发杀毒软件误报，或导致 opcode 缓存失效
• 真正的商业保护应靠授权机制、API 接口隔离、SaaS 化部署，而非藏代码

需要隐藏逻辑？换思路：前后端分离 + API 保护

如果目标是不让用户知道业务规则或算法（比如优惠计算、支付校验），正确做法是：

• 把核心逻辑放在服务端 PHP 接口中，前端只调用结果（AJAX/Fetch）
• 接口加基础防护：Token 验证、频率限制、Referer/IP 白名单（视场景而定）
• 敏感操作（如扣款、发券）必须服务端二次校验，不能信任前端传来的任何参数