报错“Cannot find local boundary”源于请求体不符合multipart/form-data规范，核心是boundary缺失或格式错误。需检查Content-Type头中boundary声明是否合规、请求体首尾分隔符及换行符是否正确，并优先使用FormData自动构造。
这个报错不是XAMPP本身的问题，而是PHP解析器在读取 multipart 请求体时，没找到合法的 boundary 字符串 —— 本质是请求格式不合规，XAMPP（确切说是其中的 PHP + Apache）只是暴露了这个校验。
为什么 XAMPP 会报 “Cannot find local boundary”
PHP 的 $_FILES 机制依赖底层 CGI/SAPI 层正确识别 multipart 边界。一旦请求头中的 Content-Type 声明了 multipart/form-data，但请求体里没有按 RFC 2046 规范写出对应的 --{boundary} 分隔线，或分隔线前后换行符（\r\n）缺失/错乱，PHP 就会直接放弃解析并抛出该错误。
- 常见诱因：前端用
fetch或axios手动拼接 multipart body，却漏写\r\n或边界结尾的--{boundary}-- - 另一个高频场景：表单用了
enctype="multipart/form-data"，但提交时 JS 拦截了原生提交、又没正确构造FormData对象（比如直接往FormDataappend 了 ArrayBuffer 而非Blob） - XAMPP 默认配置对边界格式更敏感，不像生产 Nginx+PHP-FPM 环境可能容忍部分格式瑕疵
检查并修复 Content-Type 头里的 boundary 声明
浏览器开发者工具 Network 标签页中点开上传请求，看 Request Headers 里的 Content-Type 是否形如：multipart/form-data; boundary=----WebKitFormBoundaryabc123。重点检查：
- 有没有多余空格，比如
boundary = ----...（等号前后不能有空格） - 有没有误加
charset=UTF-8——multipart/form-data不允许带charset参数，加了就会让 PHP 拒绝解析 - boundary 值是否与请求体开头第一个分隔符完全一致（大小写、符号、长度）
验证请求体是否符合 multipart 格式规范
在 Network 面板中点击请求 → 查看 Request Payload（或 Preview），手动确认结构是否满足以下三点：
XAMPP 8.0.30 是一款免费、开源的跨平台 Web 服务器集成包，专为快速搭建本地 PHP 开发环境而设计。该版本核心组件包括：Apache 2.4.56、MySQL 8.0.33、PHP 8.0.30、phpMyAdmin 5.2.1 等。它支持 Windows、Linux 和 macOS 系统，可让开发者在个人电脑上轻松模拟服务器环境，无需复杂配置即可运行 WordPress、Thin
- 首行必须是
--{boundary}（注意前面两个短横，后面紧跟 boundary 值，无空格） - 每个字段之间用
\r\n--{boundary}\r\n分隔，末尾用\r\n--{boundary}--\r\n结束 - 每个 part 必须包含
Content-Disposition头，例如Content-Disposition: form-data; name="file"; filename="test.jpg"，且该头与实际数据之间必须有一个空行（\r\n\r\n）
如果用 JS 手动构造，宁可少拼、别多拼 —— 直接用 new FormData() 是最稳妥的，它自动处理 boundary 和换行。
PHP 端临时诊断：绕过 $_FILES 直接读原始流
若仍不确定问题出在客户端还是服务端，可在 PHP 脚本开头加一段调试代码：
file_put_contents('/tmp/raw_request', file_get_contents('php://input'));
然后检查生成的文件内容是否真有 boundary 行、是否有非法字符（如 BOM、中文空格）、是否以 --{boundary}--\r\n 正确收尾。这能排除 Apache 模块（如 mod_security）提前截断请求体的可能。
真正卡住的地方往往不是 boundary 生成逻辑，而是换行符和空行 —— 这些细节在本地开发环境里特别容易被忽略，但 PHP 解析器一点不含糊。
