isdelete() 可直接判断 delete 请求，但需确保请求被正确识别：原生 delete（如 fetch）或 post 伪装（含 _method=delete 隐藏字段）；其依赖 request 实例状态，而 is_delete 是启动时确定的静态常量。
直接用 isDelete() 就能判断，但必须确保请求真被识别为 DELETE 类型——浏览器不原生支持表单发 DELETE，多数情况实际走的是 POST + _method=DELETE 伪装。
ThinkPHP 中 isDelete() 的两种生效路径
框架识别 DELETE 请求不是只看 $_SERVER['REQUEST_METHOD']，而是分两层：
- 原生 DELETE：前端用
fetch或axios显式发DELETE请求，且 Web 服务器（Nginx/Apache）未拦截或重写该方法 - 伪装 DELETE：前端用
method="post"表单提交，并带隐藏字段<input name="_method" value="DELETE">，ThinkPHP 在初始化 Request 对象时会自动检测并覆盖请求类型
无论哪种，只要 Request 对象完成初始化，isDelete() 就返回 true。但注意：若你手动 new Request 实例且未传入完整环境参数，isDelete() 可能失效。
isDelete() 和 IS_DELETE 常量的区别
两者都能判断，但行为不同：
-
IS_DELETE是全局常量，在框架启动早期就根据当前请求解析结果定义，值为布尔true或false，不可变，适合在配置或静态上下文中用 -
isDelete()是 Request 对象的实例方法，依赖当前 Request 实例状态，支持链式调用（如request()->isDelete()），也支持注入后在控制器中复用 - 如果在中间件或钩子中提前修改了 Request 实例（比如手动调用
setMethod('PUT')），isDelete()结果会随之改变，而IS_DELETE不会
为什么有时 isDelete() 返回 false，但 $_SERVER['REQUEST_METHOD'] === 'DELETE' 是 true？
这是典型“识别优先级”问题，常见于以下场景：
- 你用了
Request::instance()->isDelete()，但该实例是在框架初始化前手动创建的，没走完整的请求解析流程 - 启用了
var_method配置（如设为_m），但前端仍传_method，导致伪装逻辑未触发，框架退回到原始REQUEST_METHOD判断 —— 此时需确认配置与前端字段名一致 - 某些安全模块（如 WAF、云防护）会把 DELETE 请求重写为 POST 并丢弃原始 method，此时
$_SERVER['REQUEST_METHOD']已被篡改，isDelete()自然失效
调试时建议加一行：dump(request()->method(), $_SERVER['REQUEST_METHOD']);，对比两个值是否一致。
DELETE 请求体里的数据怎么取？isDelete() 不负责这事
isDelete() 只管判断类型，不读取数据。DELETE 请求若带 JSON（如 { "id": 123 }），必须手动处理：
- 不能依赖
input('id')或$request->param('id')—— 这些默认只解析$_GET/$_POST，而 DELETE 不进$_POST - 正确做法是：
$raw = file_get_contents('php://input');，再json_decode($raw, true) - ThinkPHP6+ 可用
request()->getRawInput()获取原始输入流，比直接操作php://input更安全（它会缓存一次读取结果） - 注意：
php://input在Content-Type: application/x-www-form-urlencoded时为空，这种编码方式不适合 DELETE，应改用application/json
最易忽略的一点：如果你在控制器里先调了 input() 或 param()，再调 getRawInput()，可能拿不到数据 —— 因为部分版本的 ThinkPHP 会在首次调用 param() 时提前消费掉 php://input 流。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
