上传音频本身不触发SQL注入，风险在于将不可信的文件名或$_POST数据拼接进SQL语句；必须用PDO预处理语句（禁用模拟预处理、显式utf8mb4字符集）写入所有元数据，清理文件名和扩展名白名单仅防路径遍历或上传恶意类型，不能替代SQL注入防护。
上传音频本身不会触发SQL注入，但如果你把用户提交的文件名、元数据（如$_POST['title']）、或数据库写入逻辑中混入了拼接SQL的操作，风险就来了。核心问题不是“上传”，而是“怎么存”。
为什么move_uploaded_file()不防SQL注入
PHP的move_uploaded_file()只负责把临时文件移到指定路径，它不碰数据库，也不解析SQL。真正危险的是你后续用$_FILES['audio']['name']或$_POST字段直接拼进INSERT语句里——比如："INSERT INTO tracks (filename, title) VALUES ('" . $_FILES['audio']['name'] . "', '" . $_POST['title'] . "')"。这种写法哪怕只传一个单引号，就能让整条SQL崩掉。
- 音频文件名不可信：用户可重命名
evil.mp3为test'); DROP TABLE tracks; --.mp3 -
$_POST字段同样危险：标题、作者、标签等全属外部输入，必须隔离处理 - 即使你校验了文件类型（如
mime_content_type()），也不能代替SQL层防护
必须用PDO预处理语句写入音频元数据
所有入库字段（包括$_FILES['audio']['name']、$_POST['title']、$_POST['artist']）都要走prepare() + execute()，不能字符串拼接。
- 连接时强制启用异常模式和真实预处理：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)，否则MySQL驱动可能在客户端模拟预处理，绕过部分防护 - 字符集必须显式声明为
utf8mb4，防止宽字节注入干扰参数边界 - 示例写法：
$stmt = $pdo->prepare("INSERT INTO audio_files (original_name, title, artist, file_path) VALUES (:name, :title, :artist, :path)"); $stmt->execute([ ':name' => $_FILES['audio']['name'], ':title' => $_POST['title'] ?? '', ':artist' => $_POST['artist'] ?? '', ':path' => $safe_storage_path ]);
文件名入库前要清理，但清理≠防注入
清理文件名（如用pathinfo()取扩展名、preg_replace()过滤非法字符）是好习惯，但它解决的是路径遍历或存储混乱问题，**不能替代预处理语句防SQL注入**。
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖
addslashes()或mysql_real_escape_string()：它们已被淘汰，且在预处理语句下多余甚至有害 - 白名单验证扩展名是必要的（如只允许
mp3、wav、ogg），但这是另一层防御，和SQL注入无关 - 如果业务需要动态表名（如按月份分表），必须用白名单校验：
$table = in_array($_POST['month'], ['2026_07', '2026_08']) ? $_POST['month'] : 'audio_default';，再拼进SQL——这种场景无法用预处理，只能靠白名单兜底
最容易被忽略的一点：很多人以为“我只对文件内容做校验，SQL就安全了”，其实只要有一个$_POST字段漏过预处理，整张表就可能沦陷。防护必须覆盖所有数据库写入点，一个都不能少。
