MySQL 1064 错误源于 SQL 语法或 PDO 调用方式错误，非 phpEnv 配置问题；pdo_query() 不支持 :param 占位符，须用 prepare()+execute()；开启通用日志可查真实执行 SQL；不同 MySQL 版本语法兼容性差异大。
phpEnv 本身不解决 MySQL 1064 错误——它只是本地开发环境套件，错误根源永远在 SQL 语句或 PDO/MySQLi 的调用方式上。你看到的 1064 报错，99% 是代码写法问题，不是 phpEnv 配置导致的。
pdo_query() 调用含 :param 占位符的 SQL 必然报 1064
这是 phpEnv 环境中最常踩的坑：在 pdo_query()（或 PDO::query()）里直接写带命名占位符的语句，比如：
SELECT * FROM users WHERE id = :uid
MySQL 根本不认识 :uid，它会原样传给服务器，结果就是 near ':uid' 报错。这不是 phpEnv 的锅，是调用方式错了。
-
PDO::query()只能执行静态 SQL，不解析任何占位符 - 含
:xxx或?的语句，必须走PDO::prepare()+PDOStatement::execute() - phpEnv 默认启用
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，所以错误会立刻抛出，反而利于定位
phpEnv 中查看真实执行的 SQL 很简单
phpEnv 自带的 MySQL 日志开关藏得浅，但很多人没开。在 phpEnv 控制面板 → MySQL → 配置 → 勾选「启用通用日志」，重启 MySQL 后，日志路径通常是 C:\phpEnv\MySQL\data\mysql.log（Windows）或 /usr/local/phpenv/mysql/data/mysql.log（macOS/Linux）。
立即学习“PHP免费学习笔记（深入）”；
- 日志里能看到 MySQL 实际收到的完整 SQL，和你写的是否一致一目了然
- 特别适合排查粘贴进来的 SQL 是否混入了中文引号、BOM 头、不可见 Unicode 字符
- 如果日志里出现
SELECT * FORM users，那问题不在 PHP，而在你复制 SQL 的源头
phpEnv 的 MySQL 版本差异会放大 1064 错误
phpEnv 允许切换 MySQL 5.7 / 8.0 / 8.4，而不同版本对语法容忍度差别极大。比如：
- 在 MySQL 5.7 写
WITH t AS (SELECT 1) SELECT * FROM t，直接报 1064（CTE 不支持） - 在 MySQL 8.0+ 写
SELECT user, order FROM log，order是保留字，必须写成`order` - phpEnv 面板右下角显示当前 MySQL 版本，写复杂 SQL 前务必确认版本兼容性
真正卡住人的从来不是“怎么修 1064”，而是没意识到 prepare() 和 query() 是两条完全不兼容的路径；以及忽略了 phpEnv 日志这个现成的“SQL 显微镜”。
