defaultDocument 节点必须置于 <system.webServer> 下而非 <system.web>，否则不生效；需确保 enabled="true"、文件物理存在且大小写匹配，并用 <clear/> 清空默认列表后显式添加所需文件。
defaultDocument 节点必须放在 <system.webServer> 下，不是 <system.web>
很多人改了 defaultDocument 没生效，第一反应是缓存或权限问题，其实八成是放错位置了。IIS 7+ 的默认文档配置只认 <system.webServer> 下的 <defaultDocument>，<system.web> 里的同名节点完全被忽略——那是给旧版 ASP.NET 管理器用的，和 IIS 运行时无关。
实操建议：
- 检查 Web.config 是否在
<configuration>→<system.webServer>下有<defaultDocument>，而不是混在<system.web>里 - 如果用的是 IIS Express（比如 VS 默认调试），同样只读
<system.webServer>，别被项目属性页里的“默认文档”设置误导 - 删掉
<system.web>中的<defaultDocument>，避免后续维护时误以为它起作用
启用 enabled="true" 并确保文件存在，否则 403.14 错误照常出现
<defaultDocument enabled="true"> 是默认值，但显式写出来更稳妥；真正卡住的是列表里写的文件名，在物理路径下根本不存在——IIS 不会跳过缺失项去试下一个，而是直接报 HTTP Error 403.14 - Forbidden（目录浏览已禁用）。
常见错误现象：
- Web.config 里写了
<add value="index.html" />，但实际只有index.htm - 大小写不一致：Linux 风格部署时，
Home.aspx和home.aspx被当成不同文件 - 路径没问题，但文件被 .gitignore 或发布脚本漏掉了，本地能跑，服务器 403
实操建议：
- 用 IIS 管理器的“默认文档”功能页核对当前生效的顺序和启用状态，比手查 XML 更直观
- 临时开启目录浏览（
<directoryBrowse enabled="true" />），直接看文件是否真在那儿
顺序决定优先级，<clear /> 再 <add> 是最安全的写法
IIS 自带一组默认值（Default.htm、Default.asp、index.htm、index.html、iisstart.htm），你加的只是追加在后面。如果不先 <clear />，你的 app.js 可能排第 20 位，永远轮不到。
使用场景：
- 纯静态站点只想用
index.html，其他全禁 - SPA 应用需要把
index.html放第一位，否则路由刷新 404 - ASP.NET Core 托管在 IIS 下，虽然 Kestrel 处理路由，但 IIS 仍会按 defaultDocument 列表尝试匹配静态入口
示例片段（推荐写法）：
<system.webServer>
<defaultDocument enabled="true">
<clear />
<add value="index.html" />
</defaultDocument>
</system.webServer>Web.config 修改后不生效？别只刷新浏览器，要确认 IIS 配置加载时机
Web.config 是实时生效的，但有两个隐藏条件：一是文件保存后 IIS 必须检测到变更，二是当前请求不能卡在旧 worker process 里。常见表现是改完配置，浏览器 Ctrl+F5 还是老样子，甚至重启 IIS Manager 都没用。
实操建议：
- 改完 Web.config 后，进 IIS 管理器 → 站点 → “高级设置”，点一下“物理路径”框再回车，强制触发配置重载
- 或者直接回收对应应用池（Application Pool → “Recycle…”），比等自动检测快得多
- 如果用的是 Azure App Service，Web.config 修改后需等待约 30 秒，且注意它会忽略某些本地测试有效的配置（如自定义 MIME 类型）
最容易被忽略的一点：IIS 会缓存 defaultDocument 的解析结果，哪怕文件存在、顺序正确、路径无误，只要应用池没回收，就可能沿用旧判断逻辑。别在浏览器里死磕 F5。
