的 path 必须以 / 开头且为虚拟路径前缀，不支持文件扩展名和通配符；仅允许被明确标记 allowlocation="true" 的配置节使用；多 path 按最长匹配优先，不继承；修改后需触发配置重载才生效。
location path里路径必须以/开头且不能带文件扩展名
Web.config 的 <location></location> 元素中，path 属性不是 URL 路径也不是物理路径，而是 IIS 管道识别的“虚拟路径前缀”，它只匹配请求路径（request path）的开头部分，且强制要求以 / 开头。
常见错误是写成 path="admin.aspx" 或 path="api/users"（缺开头斜杠），或者试图用通配符如 path="*.aspx"——这些全部无效，IIS 会静默忽略该 <location></location> 块，配置不生效。
-
path="/admin"✅ 匹配/admin、/admin/、/admin/user.aspx、/admin/api/data.json -
path="/api/v1"✅ 匹配所有以该前缀开头的请求，不管后缀 -
path="admin"❌ 缺少开头/，配置被跳过 -
path="/admin.aspx"❌ 虽然语法合法，但仅匹配字面路径/admin.aspx，不覆盖其子路径，通常不符合“覆盖整个 admin 目录”的预期
location 中的配置节必须允许“位置覆盖”
不是所有 <system.web></system.web> 或 <system.webserver></system.webserver> 下的配置都能被 <location></location> 覆盖。IIS 和 ASP.NET 有一套明确的“允许位置”（allowLocation）策略，由每个配置节的 schema 定义决定。
比如 <customerrors></customerrors>、<compilation></compilation>、<httpruntime></httpruntime> 默认支持 location 覆盖；但 <modules></modules>（在 <system.webserver></system.webserver> 下）默认不允许，直接放进去会报错：Configuration Error: This configuration section cannot be used at this path。
- 检查是否支持：打开
%windir%\Microsoft.NET\Framework\v4.0.30319\Config\web.config（或对应 .NET 版本路径），搜索目标配置节名，看其allowLocation="true"是否存在 - 若不支持，需改用其他机制：比如用
<system.webserver><rules></rules></system.webserver>做运行时路由判断，或拆成独立应用（Application） -
<location path="/api" allowoverride="true"></location>中的allowOverride属性仅控制子配置文件能否再覆盖它，不解决“本节是否允许出现在 location 中”的根本问题
嵌套 location 与继承规则容易误判
<location></location> 不支持真正意义上的嵌套（即一个 <location></location> 里再写另一个），但多个同级 <location></location> 可按 path 长度优先匹配——越长的 path 优先级越高。这点常被当成“继承”来理解，其实只是匹配顺序。
例如：<location path="/admin"></location> 和 <location path="/admin/user"></location> 同时存在，访问 /admin/user/profile.aspx 时，只有后者生效；前者完全不参与。但如果你只写了前者，它就会覆盖整个 /admin/... 范围。
- 不存在“父 location 提供默认值，子 location 只补丁修改”的逻辑——每个
<location></location>是完全独立的配置作用域 - 如果两个
path有重叠（如/api和/api/v2），IIS 总是选最长匹配项，无需手动排序 - 注意：空
path（即<location></location>不写 path）等价于path="/"，它是最底层兜底，但会被任何更具体的 path 覆盖
Web.config reload 触发时机与缓存陷阱
IIS 不会在每次请求时重新解析 Web.config。它只在首次加载或检测到文件变更时重建配置树。而 <location></location> 的匹配发生在请求进入 pipeline 的早期（如 BeginRequest），所以看似“动态”的 path 匹配，实际依赖的是启动时已构建好的内部路由映射表。
这意味着：修改了 <location path="/xxx"></location> 后，必须触发配置重载（如修改 Web.config 时间戳、iisreset、或回收 AppPool），否则新配置永不生效。更隐蔽的问题是，开发时习惯性刷新浏览器，却忘了 Web.config 没变，导致反复排查“为什么配置不生效”。
- 验证是否加载成功：在对应路径下抛个异常（如故意写错一个配置项），看是否报出
Configuration Error—— 如果没报，说明该<location></location>根本没被读取 - 不要依赖浏览器缓存来判断配置效果；用 curl 或 Postman 发起干净请求，并检查响应头中的
X-AspNet-Version或自定义 header 来确认执行路径 - 在集成环境中，若使用 web deploy 或 CI/CD 覆盖 Web.config，注意文件时间戳可能未更新，IIS 无法感知变更
