在thinkphp 6中，应通过自定义中间件forcehttpsmiddleware实现https强制跳转：先判断isssl()，非https且非ajax/cli/静态资源时，用request->url(true)生成完整url并301重定向；需配置trust_proxy及trust_proxies支持slb/cdn。
ThinkPHP 6 如何让所有路由自动跳转 HTTPS
直接在中间件里做协议判断最稳妥，别依赖 Nginx 配置或 $_SERVER['HTTPS'] 的不可靠值。TP6 的 TrustProxies 中间件默认不信任反向代理传来的 X-Forwarded-Proto，所以即使你用 CDN 或 SLB，也得手动配置信任链。
实操建议：
- 在
app/middleware.php中注册自定义中间件（如ForceHttpsMiddleware），放在全局中间件数组最前面 - 中间件内检查
$request->isSsl()，不是则用redirect()发起 301 跳转到https://开头的当前 URL - 务必用
$request->url(true)拼接完整 URL，它会保留 query、path 和 fragment；别手动拼$_SERVER变量，容易漏掉端口或编码问题 - 如果部署在阿里云 SLB、腾讯云 CLB 或 Cloudflare 后面，需先在
config/app.php中设置：'trust_proxy' => true，并确保trust_proxies包含你的代理 IP 段（如['10.0.0.0/8', '172.16.0.0/12']）
为什么 $_SERVER['HTTPS'] === 'on' 在某些环境总返回 false
因为这个值只在 Apache mod_ssl 直连时可靠；Nginx 默认不设它，SLB/CDN 更不会透传。TP6 的 Request::isSsl() 底层其实也是看这个变量，所以不配代理信任，就永远判不准。
常见错误现象：
- 本地开发用 Valet 或 XAMPP 测试正常，上线后跳转失效或无限重定向
- Cloudflare 开启“始终使用 HTTPS”后，TP6 仍认为是 HTTP 请求，导致登录态丢失或 CSRF 校验失败
- 在容器中部署时，
$_SERVER['HTTPS']完全不存在，isset($_SERVER['HTTPS'])返回 false
根本原因：TP6 默认不解析 X-Forwarded-Proto 头。必须显式启用代理信任，并确认该 header 真实存在且未被清洗。
如何安全地重定向又不影响 API 接口和 CLI 调用
强制跳转不能无差别应用——API 接口通常要求保持协议一致（比如小程序调用必须是 HTTPS），但 CLI 命令（如 php think queue:work）压根没有 request 对象，硬判会报错。
使用场景与判断逻辑：
- 先用
$request->isAjax()或$request->header('accept') === 'application/json'区分接口请求，这类请求不应重定向，只返回 400 或提示 - 用
PHP_SAPI === 'cli'排除命令行执行，避免redirect()报 headers already sent - 对静态资源（
.js、.css、.png）可加路径前缀过滤，比如str_starts_with($request->url(), '/static/')，跳过重定向节省开销 - 若项目用了多子域名（如
api.example.com、admin.example.com），重定向时注意不要把admin错跳成www
重定向状态码选 301 还是 302？TP6 默认是哪个
TP6 的 redirect() 默认发的是 302，浏览器不会缓存跳转，适合调试；但上线后应改成 301，否则搜索引擎可能同时收录 HTTP 和 HTTPS 版本，影响 SEO。
参数差异与性能影响：
-
redirect($url, 301)显式指定状态码，比默认 302 多一次 header 设置，但可忽略不计 - 301 会被浏览器和 CDN 缓存，一旦配错（比如误跳到错误域名），清除成本高，建议上线前用
curl -I http://example.com验证响应头 - 部分老旧客户端（如某些嵌入式设备）对 301 处理异常，若服务需兼容工业终端，可先灰度用 302 观察一周再切
复杂点在于：重定向逻辑一旦混进中间件，就很难针对某个模块关闭。比如后台管理要 HTTPS，但内网调试接口想临时走 HTTP，就得加白名单配置，而不是写死判断。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
