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 动态执行），实际作用极小：
立即学习“PHP免费学习笔记（深入）”；
- 它们无法阻止有权限访问服务器的人查看原始代码（比如运维、合作开发者）
- 绝大多数混淆可被一键还原（在线解密工具秒破），反而影响调试和性能
- 过度混淆可能触发杀毒软件误报，或导致 opcode 缓存失效
- 真正的商业保护应靠授权机制、API 接口隔离、SaaS 化部署，而非藏代码
需要隐藏逻辑？换思路：前后端分离 + API 保护
如果目标是不让用户知道业务规则或算法（比如优惠计算、支付校验），正确做法是：
- 把核心逻辑放在服务端 PHP 接口中，前端只调用结果（AJAX/Fetch）
- 接口加基础防护：Token 验证、频率限制、Referer/IP 白名单（视场景而定）
- 敏感操作（如扣款、发券）必须服务端二次校验，不能信任前端传来的任何参数
