在 nginx 中匹配特定的静态文件后缀，最直接且高效的方法是在 location 块中使用正则表达式修饰符 ~ 或 ~*。通过编写精确的正则模式（例如 ~ \.js$），nginx 会在处理请求时直接进行正则匹配，从而跳过前缀匹配的开销并精准定位目标资源。
如何配置以区分大小写匹配 JS 文件
要区分大小写地匹配特定后缀，需使用带 ~ 修饰符的 location 指令。该方式会执行严格的大小写敏感正则匹配，确保只有完全符合模式的请求才会进入该分支。
server {
listen 80;
server_name example.com;
# 区分大小写匹配 .js 文件
location ~ \.js$ {
root /var/www/html;
add_header Content-Type 'application/javascript';
try_files $uri =404;
}
# 默认位置
location / {
root /var/www/html;
index index.html;
}
}
在上述配置中，location ~ \.js$ 定义了一个正则匹配规则。当客户端请求 /app/main.js 时，Nginx 会命中此规则并将根目录设置为 /var/www/html，最终尝试读取 /var/www/html/app/main.js。如果请求的是 .JS 或 .Js，由于大小写不匹配，请求将不会进入此块，而是继续向下匹配其他 location 或直接返回 404。这种写法适用于对文件名大小写有严格要求的场景。
如何配置以忽略大小写匹配 CSS 文件
若希望忽略大小写进行匹配，应使用 ~* 修饰符。该修饰符告诉 Nginx 在执行正则匹配时不区分大小写，从而兼容不同操作系统或构建工具生成的不同后缀格式。
server {
listen 80;
server_name example.com;
# 忽略大小写匹配 .css 文件
location ~* \.css$ {
root /var/www/html;
add_header Content-Type 'text/css';
expires 30d;
try_files $uri =404;
}
location / {
root /var/www/html;
index index.html;
}
}
在此配置中，location ~* \.css$ 能够同时匹配 .css、.CSS 和 .Css 等变体。Nginx 在处理这些请求时，会统一应用 expires 30d 缓存策略并设置正确的 MIME 类型。这种灵活性在处理由不同环境生成的静态资源时非常有用，避免了因大小写不一致导致的缓存失效或 404 错误。
正则匹配与精确前缀匹配的优先级冲突如何解决
当存在多个 location 规则时，Nginx 遵循“最长前缀匹配优先，正则匹配中断”的原则。如果正则表达式 ~ 或 ~* 匹配成功，Nginx 将立即停止搜索并使用该规则，即使存在更长的前缀匹配规则也不会生效。因此，必须确保正则规则的优先级高于可能产生冲突的前缀规则。
server {
listen 80;
server_name example.com;
# 精确前缀匹配：优先级高但仅匹配固定路径
location = /exact.js {
return 200 "Exact match";
}
# 正则匹配：一旦匹配成功即终止搜索
location ~ \.js$ {
root /var/www/html;
}
location / {
root /var/www/html;
}
}
在上述示例中，如果请求 /exact.js，Nginx 首先检查精确前缀匹配 = /exact.js，发现完全一致，因此直接返回 "Exact match"，后续的 ~ \.js$ 规则根本不会被执行。然而，如果请求是 /other/file.js，它不匹配 = /exact.js，Nginx 会继续查找，此时 ~ \.js$ 匹配成功，Nginx 便停止搜索并使用该正则规则。这种机制确保了精确控制与灵活匹配可以共存，开发者只需注意避免在正则之前放置过于宽泛的前缀匹配即可防止意外拦截。
