GoDaddy 的 Windows 共享主机并不支持 .htaccess,也不会执行 Apache 环境常用的 mod_rewrite 规则。也就是说,你之前在 Linux 主机上已经测试正常的 ThinkPHP 伪静态配置,迁移到这里后通常会直接失效——问题并不是规则写错了,而是服务器压根不会解析这套配置。

因此,核心结论很明确:在 GoDaddy Windows 主机上,ThinkPHP 伪静态规则必须改用 IIS 的 web.config 来实现,同时还要同步检查并调整 ThinkPHP 的路由配置。
GoDaddy Windows 主机无法启用 mod_rewrite
GoDaddy 的 Windows 共享主机(例如 Classic Hosting 套餐)运行环境是 IIS,而不是 Apache。它不会加载 mod_rewrite.so,也不会识别或解析 .htaccess 文件。即使你上传了一份完整的 Apache RewriteRule 规则,服务器通常也会直接忽略,严重时甚至会返回 500 错误。
判断方法也很直接:查看 phpinfo() 页面中的 Loaded Modules 字段,你不会看到 mod_rewrite 模块。另外,在 GoDaddy 的 Windows 主机环境下,.htaccess 基本没有任何实际作用,保留或删除都不会影响结果。至于想通过 AllowOverride FileInfo 或修改 httpd.conf 来开启重写功能,也不现实——共享主机用户并没有服务器级配置权限。
唯一可行方案:改用 IIS 的 web.config 重写规则
好消息是,GoDaddy Windows 主机通常支持 IIS URL Rewrite 模块,前提是主机环境已经启用该组件。你需要使用 web.config 来替代 .htaccess 完成 URL 重写,而且要注意,IIS 的规则语法和 Apache 完全不同,不能把 Apache 伪静态规则原封不动复制过来。
具体操作是:在网站根目录创建一个名为 web.config 的文件(注意文件名和扩展名不要写错)。文件内容必须采用标准 XML 格式。下面提供一个适用于 ThinkPHP 5/6 的 pathinfo 模式伪静态规则示例,可兼容 index.php/s/xxx 或 /xxx 这类 URL 结构:
需要特别注意的是,url="index.php?s={R:1}" 这一行才是 ThinkPHP 在 IIS 下实现伪静态的关键。因为 ThinkPHP 默认通过 $_GET['s'] 解析路由,所以重写目标必须写成 index.php?s={R:1},而不能写成 index.php/{R:1}。如果你的网站并不是部署在根目录,而是放在子目录中(例如 https://yoursite.com/sub/),那么 中的 index.php 也要改成相对路径,例如 sub/index.php?s={R:1}。
另外,还有一个常见问题必须提前说明:部分 GoDaddy 老版本 Windows 主机并没有预装 URL Rewrite Module。如果你上传 web.config 之后网站直接报 500 错误,那么大概率就是主机环境缺少这个模块。这种情况下,最稳妥的做法是联系 GoDaddy 客服确认主机是否支持 IIS URL Rewrite;如果明确不支持,那基本只能更换主机方案。
ThinkPHP 路由配置必须同步调整
即使 web.config 配置已经生效,如果 ThinkPHP 框架本身的路由设置没有同步处理,访问请求依然可能出现 404。因此,下面几个关键项一定要重点检查:
- 确认
config/app.php中的'url_route_on' => true已经开启。无论是 ThinkPHP 5 还是 ThinkPHP 6,这一步都很重要。 - 关闭或清空
url_html_suffix:建议设置为''。否则框架自动生成的链接可能会带有.html后缀,而当前web.config规则未必能正确匹配该后缀,最终导致伪静态访问失败。 - 不要继续使用
__ROOT__手动拼接 URL,建议统一改用url()辅助函数来生成链接地址,这样更容易保证路径和重写规则保持一致。 - 如果你使用的是 TP6,并且开启了多应用模式,那么
s参数中通常还需要包含应用名,例如index.php?s=api/v1/user。在定义路由时,也要同时留意命名空间前缀是否正确。
还有一个经常被忽略但非常关键的细节:web.config 中的 属于服务器内部重写,它不会改变浏览器地址栏中显示的 URL。但是,如果你在 ThinkPHP 路由或控制器里使用了重定向(例如 redirect()),而重定向后的目标地址又没有被 web.config 规则正确匹配,那么访问就会直接中断或出现死链。因此,所有对外访问的 URL,都必须确认能够被 web.config 中的 规则覆盖到,这一步一定要逐项检查清楚。
