hash路由和nginx配置

非 Hash 路由（History 模式）

整个访问过程可以理解为 两个阶段，而 Nginx 只参与第一个阶段。

把你的单页应用想象成一家只有一个房间的酒店：这个房间就是 index.html（大堂）。

第一阶段：找酒店（Nginx 的工作）

• 客人（浏览器）打电话给前台（Nginx）说：“你好，我要去 301 号房。”
  （请求 /kanban/taoli-dashboard）
• 前台（Nginx）一看地图，发现酒店里只有 大堂（index.html），根本没有 301 这个物理房间。
• 如果前台很死板，他会直接说：“没有这个房间！”然后挂断电话。
  这就是 404。
• 但我们给前台配了一个万能规则（try_files）：
  “只要客人找的房间不存在，别废话，直接把电话转接到大堂（index.html）去！”
• 于是，前台把电话转接到了大堂。

到这里，Nginx 的工作就结束了。它确实没找到 301 房间，它只是执行了 “找不到就转接大堂” 的规则。

第二阶段：在酒店内导航（Vue 的工作）

• 客人（浏览器）的电话接通了大堂（index.html）。
• 这时，酒店里的智能管家（Vue Router）接过电话，问客人：“先生，您想去哪里？”
• 客人说：“我要去 301 号房。”
• 智能管家（Vue Router）看了看手里的电子地图（你的路由配置 routes），发现 301 对应的是“健身房”。
• 于是，管家在大堂里打开了健身房的灯光和器械（渲染 TaoliDashboard 组件），对客人说：“好了，您现在就在 301 号房了。”

你看，客人最终“到达”了 301，但这完全是智能管家在酒店内部完成的，前台（Nginx）根本不知道，也不关心。

Hash 模式（带 #）

当你访问 http://192.168.1.222/kanban/#/taoli-dashboard 时：

• 浏览器（非常懂事）：它看到 #，心里想：“哦，这是锚点，是页面内部跳转，不用麻烦服务器了。”
• 浏览器动作：它只向 Nginx 发送请求 GET /kanban/。
• Nginx（非常轻松）：它收到 /kanban/，心想：“找目录？好的，给你 index.html。”
• 结果：Nginx 甚至都不需要触发 try_files 的“兜底”机制，因为它收到的请求就是合法的目录路径。

比喻

你给前台（Nginx）打电话，说“我要去大堂”。前台说“好，请进”。等你进了大堂，你自己看着墙上的指示牌（# 后面的内容）去了健身房。前台压根不知道你去了健身房。