1. 这不是“配环境”是交付一个能跑在生产服务器上的完整系统Vue ASP.NET Web API 前后端分离项目发布部署这八个字背后藏着的不是“点几下鼠标就能上线”的幻觉而是一整套工程闭环前端构建产物如何与后端服务协同、静态资源路径怎么不被404吞掉、跨域问题在生产环境里根本不存在——因为它压根不该出现在生产环境里、token怎么从登录态安全流转到每次请求头、IIS或Kestrel怎么扛住真实用户并发、甚至一个favicon.ico 404都可能暴露你的目录结构。我做过27个上线项目其中19个卡在部署环节不是代码写错了而是对“发布”二字的理解停留在本地 npm run build 和 dotnet publish 的机械执行上。真正决定项目能否稳定运行的恰恰是那几十行配置、几个路径参数、一次反向代理的映射规则以及你有没有在凌晨三点盯着 IIS 日志查500错误时突然意识到 web.config 里 的 customHeaders 写错了顺序。这个过程适合三类人刚用 Vue CLI 搭完登录页、正准备把项目交给客户验收的前端同学接手了前端打包产物、却不知道该往 IIS 哪个文件夹扔的 .NET 开发者还有那些被“前后端分离”概念绕晕、以为只要接口通了就万事大吉的项目经理。它不讲 Vue 的响应式原理也不深挖 ASP.NET Core 的中间件管道只聚焦一件事让 build 出来的 dist 文件夹和 publish 出来的 dll 文件在 Windows Server 或 Linux 服务器上像在你本机 localhost:8080 localhost:5000 那样稳稳当当地跑起来并且扛得住真实流量。接下来所有内容全部来自我踩过的坑、改过的配置、重装过三次的 IIS、以及客户服务器上那段被反复注释又取消注释的 nginx location 块。2. 整体设计思路为什么必须拆成“前端静态托管”“后端API服务”两层2.1 前后端分离的本质不是技术选型而是职责边界很多人误以为“用了 Vue 和 Web API 就叫前后端分离”其实这只是表象。真正的分离是把“谁负责呈现页面”和“谁负责提供数据”彻底解耦。Vue 应用编译后是一堆 HTML、CSS、JS 和图片它们不需要服务器执行任何逻辑只需要被 HTTP 服务器原样返回给浏览器而 ASP.NET Web API 是一个独立的进程监听某个端口比如 5000只做一件事接收 HTTP 请求、校验 token、查数据库、返回 JSON。这两者之间不应该存在任何代码级依赖也不应该共享同一个进程或应用池。我见过最典型的反模式是把 Vue 的 dist 文件夹直接塞进 ASP.NET MVC 的 Views 目录再用 Controller 返回一个空 View靠 script 标签加载 index.js —— 这看起来像分离实则把前端构建产物变成了后端项目的“资源文件”一旦要升级 Vue 版本或更换构建工具就得重新编译整个 .NET 解决方案完全违背了分离的初衷。所以部署的第一步就是明确物理隔离前端走 Nginx/IIS 静态文件托管后端走 Kestrel/IIS 反向代理或独立进程。这种设计带来三个硬性好处发布解耦前端团队可以独立发布新版本只需替换 dist 文件夹内容不影响后端服务进程后端团队升级框架或修复接口前端无需重新构建。性能优化静态资源由擅长处理高并发小文件的 Web 服务器如 Nginx直接返回不经过 .NET 运行时首屏加载速度提升 30%~60%API 请求则由 Kestrel 这种高性能 HTTP 服务器专注处理。安全加固前端资源可配置强缓存Cache-Control: public, max-age31536000减少重复请求后端 API 则可通过 IIS 的 IP 限制、请求过滤等模块做第一道防线两者策略互不干扰。2.2 为什么不能直接用 Vue DevServer 代理到后端生产环境没有 devServerVue CLI 的 vue.config.js 里写个 devServer.proxy本地开发时确实方便。但这是开发阶段的“模拟”本质是 webpack-dev-server 启动了一个中间层把 /api/ 开头的请求转发给 http://localhost:5000。这个 proxy 在 build 之后就彻底消失不会打包进任何产物里。很多新手把本地能跑通的代码直接扔到服务器发现所有接口 404第一反应是“后端没启动”其实是前端页面里的 fetch(/api/login) 这个路径在生产环境里根本没人监听——因为浏览器直接向当前域名发起请求而你的 Nginx 或 IIS 根本没配置这条路由的转发规则。正确的做法是前端代码里所有 API 请求必须使用绝对路径或相对路径且该路径需与生产环境的反向代理规则严格匹配。例如约定所有 API 路径以 /api/ 开头那么 Nginx 配置就必须把 /api/ 开头的请求无条件转发到 http://127.0.0.1:5000同时前端 axios 的 baseURL 就设为 /api/而不是 http://localhost:5000/api/。这样无论前端部署在 www.example.com 还是 app.example.com只要 Nginx 规则一致请求就能精准抵达后端。2.3 ASP.NET Web API 的宿主选择Kestrel vs IIS不是二选一而是组合拳ASP.NET Core 官方文档说 Kestrel 是跨平台、高性能的 Web 服务器IIS 是 Windows 上的传统 Web 服务器。但实际部署中Kestrel 绝不单独暴露在公网。原因很现实Kestrel 缺少企业级功能比如请求压缩、SSL 卸载、IP 白名单、URL 重写、负载均衡支持。它就像一辆顶级超跑引擎强悍但没有空调、没有安全气囊、不能上高速——必须套在一个更稳健的“外壳”里。所以标准架构是Kestrel 作为应用内嵌服务器监听 localhost:5000或任意内部端口只接受来自本机的请求IIS或 Nginx作为反向代理监听 80/443 端口接收所有外部请求再根据规则把 /api/ 转发给 Kestrel。IIS 在这里不是“宿主”而是“网关”。这种组合既保留了 Kestrel 的高性能又利用了 IIS 成熟的管理界面、日志系统和安全模块。我在客户现场遇到过一次事故某同事图省事把 Kestrel 直接绑定到 0.0.0.0:5000 并开放防火墙端口结果第二天就被扫描器打爆了内存因为 Kestrel 默认不启用请求体大小限制恶意构造的超大 POST 请求直接拖垮进程。而换成 IIS 反向代理后我们能在 IIS 层面设置 requestLimits瞬间解决问题。3. 核心细节解析从构建到上线的每一步关键操作3.1 Vue 项目构建前的必改项public/index.html 与 router 的 base 配置Vue CLI 构建时默认把所有静态资源路径写成相对路径如 ./js/app.js。如果前端部署在域名根路径https://example.com/这没问题但如果部署在子路径https://example.com/admin/就会出现 JS/CSS 加载 404。根源在于浏览器解析 ./js/app.js 时会以当前页面 URL 为基准即 https://example.com/admin/ → https://example.com/admin/js/app.js。而实际文件在 https://example.com/admin/dist/js/app.js。解决方案分两步第一步修改 vue.config.js 中的 publicPath// vue.config.js module.exports { // 如果部署在根路径设为 / // 如果部署在子路径比如 https://example.com/myapp/则设为 /myapp/ publicPath: process.env.NODE_ENV production ? /admin/ : /, outputDir: dist, assetsDir: static }这个 publicPath 会注入到 index.html 的script和link标签中确保资源路径正确。第二步如果用了 Vue Router 的 history 模式即 URL 不带 #必须配置 router 的 base// router/index.js const router new VueRouter({ mode: history, base: process.env.NODE_ENV production ? /admin/ : /, routes: [...] })base 值必须与 publicPath 完全一致。否则用户直接访问 https://example.com/admin/user/1 时Nginx 会把请求转发给前端静态服务器但前端 router 找不到匹配的路由显示空白页。这是因为 history 模式下router 初始化时会读取当前 URL 的 pathname/admin/user/1然后去 routes 里匹配如果 base 设为 /它会尝试匹配 /user/1自然失败。提示如果你不确定部署路径可以在构建后手动编辑 dist/index.html把script src/js/app.js改成script src/admin/js/app.js但这只是临时救急长期维护必须靠配置驱动。3.2 ASP.NET Web API 的跨域CORS配置开发期开生产期关CORS 是开发阶段的“便利贴”不是生产环境的“安全门”。本地开发时Vue 运行在 http://localhost:8080Web API 在 http://localhost:5000浏览器同源策略会拦截请求所以我们在 Startup.cs 里加// Startup.cs public void ConfigureServices(IServiceCollection services) { services.AddCors(options { options.AddPolicy(AllowAll, builder { builder.AllowAnyOrigin() // 允许所有来源 .AllowAnyMethod() .AllowAnyHeader(); }); }); } public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { app.UseCors(AllowAll); // 启用 CORS }这段代码在开发时救命但在生产环境必须删除或禁用。原因有二一是 AllowAnyOrigin() 会返回 Access-Control-Allow-Origin: *但若响应头包含 credentials如 cookie 或 Authorization header浏览器会拒绝该响应二是它完全放弃了来源控制任何网站都能调用你的 API等于把数据库钥匙挂在门口。生产环境的正确做法是在反向代理层Nginx/IIS统一处理跨域后端代码里彻底移除 CORS 配置。因为前端和后端在生产环境共享同一个域名如 https://example.com浏览器认为它们同源根本不会触发跨域检查。所有 /api/ 请求都是从 https://example.com 发起被 Nginx 拦截并转发给后端响应再原路返回全程无跨域。我曾帮一个金融客户排查过 API 响应慢的问题最后发现是后端启用了 CORS每次请求都多了一次 PreflightOPTIONS预检而预检响应里又包含了大量不必要的 headers白白消耗了 200ms。关掉 CORS 后接口平均耗时下降 15%。3.3 Token 处理的两种落地方式localStorage vs HttpOnly CookieVue 前端登录后token 怎么存、怎么发直接影响安全性。常见方案有两种方案一存 localStorage每次请求手动添加 Authorization header// 登录成功后 localStorage.setItem(token, response.data.token) // axios 请求拦截器 axios.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config })优点简单直接JWT token 可以轻松解析 payload 查看用户信息缺点XSS 攻击可窃取 token因为 localStorage 可被 JavaScript 读取。方案二后端 Set-Cookie 返回 HttpOnly Cookie前端无需操作// 登录成功后 var cookieOptions new CookieOptions { HttpOnly true, // JS 无法读取 Secure true, // 仅 HTTPS 传输 SameSite SameSiteMode.Strict, Expires DateTime.UtcNow.AddDays(7) }; Response.Cookies.Append(auth_token, token, cookieOptions);前端完全不用管 token浏览器自动在每次请求中携带 Cookie。后端用 [Authorize] 特性自动验证。优点防 XSStoken 不在前端内存中缺点需要处理 CSRF可用 SameSiteStrict 缓解且 JWT 优势无状态、自包含被弱化因为 token 存在服务端 session 或 Redis 中。我的建议是内部管理系统用方案二面向公众的网站用方案一 前端加密存储如用 crypto-js AES 加密后再存 localStorage。前者更重安全后者更重灵活性。无论哪种都必须在后端 API 的响应头中明确设置 Access-Control-Allow-Credentials: true并在前端 axios 配置 withCredentials: true否则 Cookie 不会发送。3.4 IIS 部署 ASP.NET Web API 的五个致命细节IIS 部署不是把 publish 文件夹复制过去就完事。以下是我在 Windows Server 2016/2019 上踩过的五个必改点应用池 .NET CLR 版本必须设为“无托管代码”ASP.NET Core 应用是独立进程dotnet.exe不依赖 IIS 的 .NET 运行时。如果应用池设为 .NET CLR v4.0IIS 会试图用 w3wp.exe 加载你的 dll导致 502.5 错误。正确设置应用池 → 高级设置 → .NET CLR 版本 → 无托管代码。应用池“启用 32 位应用程序”必须与你的 SDK 匹配如果你用 x64 SDK publish应用池必须禁用 32 位反之亦然。错误会导致“找不到 dll”或“BadImageFormatException”。检查方法命令行运行dotnet --list-runtimes看输出的是 Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 还是 [C:\Program Files (x86)\dotnet\shared...]。web.config 必须存在且内容正确publish 时会自动生成 web.config但有时会被覆盖。核心内容如下?xml version1.0 encodingutf-8? configuration system.webServer handlers add nameaspNetCore path* verb* modulesAspNetCoreModuleV2 resourceTypeUnspecified / /handlers aspNetCore processPathdotnet arguments.\YourApi.dll stdoutLogEnabledtrue stdoutLogFile.\logs\stdout hostingModelinprocess environmentVariables environmentVariable nameASPNETCORE_ENVIRONMENT valueProduction / /environmentVariables /aspNetCore /system.webServer /configuration关键点processPathdotnet不是 yourapp.exehostingModelinprocess推荐性能更好stdoutLogEnabledtrue开启日志排错必备。站点绑定必须包含 HTTPS且 SSL 证书已绑定即使前端用 HTTPAPI 也必须走 HTTPS。否则浏览器会阻止混合内容HTTP 页面加载 HTTPS 资源可行但 HTTPS 页面加载 HTTP API 会被拦截。在 IIS 站点 → 绑定 → 添加 → 类型选 https端口 443SSL 证书选已安装的证书。Windows 防火墙必须放行端口Kestrel 默认监听 localhost:5000但 IIS 反向代理需要访问这个端口。防火墙默认阻止本地回环访问。解决高级安全 Windows 防火墙 → 入站规则 → 新建规则 → 端口 → TCP 5000 → 允许连接 → 作用域设为“本地回环”。注意IIS 日志默认在 C:\inetpub\logs\LogFiles\W3SVC1但 stdout 日志在你 publish 文件夹下的 logs 目录。500 错误时先看 stdout_log.txt里面会有详细的异常堆栈比 IIS 日志有用十倍。4. 实操过程从零开始部署一个可运行的 demo4.1 准备工作环境清单与权限确认在动手前必须确认以下五项缺一不可服务器操作系统Windows Server 2016 或更高版本IIS 部署或 Ubuntu 20.04Nginx systemd 部署。本文以 Windows 为例。已安装软件IIS角色服务里勾选“Web 服务器(IIS)”、“.NET Extensibility 4.8”、“HTTP 响应标头”ASP.NET Core Runtime 6.0下载地址https://dotnet.microsoft.com/download/dotnet/6.0选 Runtime不是 SDKURL Rewrite ModuleIIS 反向代理必需下载地址https://www.iis.net/downloads/microsoft/url-rewrite文件权限publish 文件夹需赋予 IIS_IUSRS 用户“读取 执行”权限logs 文件夹需额外赋予“写入”权限否则 stdout 日志无法生成。域名与证书已申请好域名如 api.example.com并安装好 SSL 证书到服务器证书存储区。网络权限服务器 80/443 端口已开放云服务器需检查安全组5000 端口仅限本机访问防火墙已按 3.4 节配置。我建议新建一个专用 Windows 用户如 deployer将其加入 IIS_IUSRS 组并用此用户登录远程桌面操作避免用 Administrator 账户引发权限混乱。4.2 Vue 前端部署Nginx 静态托管实战虽然标题是 ASP.NET但前端部署同样关键。我们用 Nginx轻量、稳定、配置直观托管 Vue 构建产物下载 Nginx for Windowshttps://nginx.org/en/download.html解压到 C:\nginx。修改 conf/nginx.confworker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 配置前端站点 server { listen 80; server_name www.example.com; # 根路径指向 dist 文件夹 location / { root C:/deploy/frontend/dist; index index.html; try_files $uri $uri/ /index.html; # history 模式必备 } # API 请求全部转发给后端 location /api/ { proxy_pass http://127.0.0.1:5000/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } # 配置 HTTPS 站点可选但强烈推荐 server { listen 443 ssl; server_name www.example.com; ssl_certificate C:/certs/example.com.crt; ssl_certificate_key C:/certs/example.com.key; location / { root C:/deploy/frontend/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass https://127.0.0.1:5001/; # 后端也走 HTTPS # ... 其他 proxy_set_header 同上 } } }关键点解释try_files $uri $uri/ /index.html确保 history 模式下用户刷新 /user/1 页面时Nginx 不返回 404而是返回 index.html由 Vue Router 处理路由。proxy_pass http://127.0.0.1:5000/末尾的/至关重要它表示“去掉 /api/ 前缀再转发”。例如请求 /api/login会被转发为 http://127.0.0.1:5000/login。如果写成proxy_pass http://127.0.0.1:5000;无斜杠则转发为 http://127.0.0.1:5000/api/login后端控制器收不到。启动 Nginx双击 nginx.exe或命令行start nginx。检查是否运行任务管理器 → 服务 → nginx.exe 进程是否存在。测试前端浏览器访问 http://www.example.com应看到 Vue 页面F12 查看 Network确认 js/css 加载正常且无 404。4.3 ASP.NET Web API 部署IIS 反向代理全流程现在部署后端在 Visual Studio 中右键 Web API 项目 → 发布 → 选择“文件夹” → 目标位置设为 C:\deploy\backend\publish。确保发布设置正确配置Release目标框架net6.0部署模式框架依赖Framework-dependent目标运行时win-x64与服务器 CPU 架构一致勾选“删除目标文件夹中的现有文件”复制 publish 文件夹全部内容到 C:\deploy\backend\。打开 IIS 管理器 → 左侧“连接”窗格 → 右键“网站” → “添加网站”网站名称MyApi物理路径C:\deploy\backend\绑定类型 httpsIP 地址全部未分配端口 443主机名 api.example.comSSL 证书选已安装的证书配置反向代理URL Rewrite选中刚创建的 MyApi 网站 → 双击“URL 重写”点击右侧“添加规则” → 选择“空白规则”名称Proxy to Kestrel匹配 URL请求的 URL → 使用正则表达式 → 模式^(.*)$条件无操作重写 → 重写 URLhttp://127.0.0.1:5000/{R:1} → 附加查询字符串勾选 → 停止处理后续规则勾选点击“应用”启动网站右键 MyApi → “启动”。检查应用池是否也处于“正在运行”状态。测试 API浏览器访问 https://api.example.com/health假设你有一个 HealthController应返回 {status:Healthy}用 Postman 调用 https://api.example.com/api/login应返回 token。实操心得IIS 的 URL Rewrite 规则比 Nginx 的 location 更容易出错。常见错误是“重写 URL”里写了 http://localhost:5000/{R:1}但 localhost 在 IIS 进程里解析失败必须用 127.0.0.1。另外规则必须放在“网站”级别不能放在“应用程序”级别否则不生效。4.4 前后端联调与最终验证三步确认法部署完成后必须进行三步验证缺一不可第一步前端独立验证打开浏览器开发者工具 → Network 标签 → 刷新页面。观察所有 JS/CSS/图片请求状态码为 200Size 列显示文件大小非 0没有 404 请求特别是 favicon.ico、manifest.json页面渲染正常Vue Devtools 显示组件树。第二步API 独立验证用 curl 或 Postman 直接请求后端curl -X POST https://api.example.com/api/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}预期返回 200 和 token。如果返回 500立刻查看 C:\deploy\backend\logs\stdout_*.log找第一行异常信息。第三步全链路验证在 Vue 页面上点击登录按钮。F12 查看 Network登录请求 URL 是 https://www.example.com/api/login注意是 www 域名不是 api请求 Method 是 POSTStatus 是 200Response Headers 里有 Set-Cookie如果用了 Cookie 方案或直接返回 token 字段后续请求如获取用户信息的 Request Headers 里有 Authorization: Bearer xxxxx。如果第三步失败90% 的原因是前端 baseURL 设错了或者 Nginx 的 location /api/ 规则没生效。此时不要猜直接在 Nginx 日志logs/access.log里搜索 “api/login”看是否有记录再检查 IIS 的 Failed Request Tracing开启后能捕获完整的请求生命周期。5. 常见问题与排查技巧实录那些凌晨三点的救火记录5.1 问题速查表高频故障与一键定位现象可能原因快速定位方法解决方案前端页面白屏Console 报错Failed to load resource: net::ERR_CONNECTION_REFUSEDNginx 未运行或 80 端口被占用命令行netstat -ano | findstr :80看 PID 对应哪个进程重启 Nginx或taskkill /PID {PID} /F杀掉占用进程API 请求返回 502 Bad GatewayIIS 反向代理未连通 Kestrel或 Kestrel 进程崩溃查看 IIS 应用池状态检查 C:\deploy\backend\logs\stdout_*.log 最后一行重启应用池确认 publish 文件夹里有 YourApi.dll 和 web.config登录成功但后续请求 401 Unauthorizedtoken 未正确添加到请求头或后端 JWT 验证失败F12 → Network → 点击一个 401 请求 → Headers → 看 Request Headers 里是否有 Authorization前端检查 axios 拦截器后端检查 Startup.cs 的 AddJwtBearer 配置Issuer 和 Audience 是否与 token 里的一致页面样式错乱字体图标显示为方块publicPath 配置错误导致 CSS 中的字体路径 404F12 → Network → Filter 输入.woff看是否 404修改 vue.config.js 的 publicPath确保与部署路径一致构建后检查 dist/css/app.css 里的 url() 路径HTTPS 页面加载 HTTP API 被浏览器拦截前端 baseURL 写了 http://或 Nginx proxy_pass 用了 http://F12 → Console看是否有Mixed Content警告前端 baseURL 改为/api/Nginx proxy_pass 改为https://127.0.0.1:5001/后端 Kestrel 启用 HTTPS5.2 我踩过的三个典型坑及独家修复技巧坑一IIS 应用池“闲置超时”导致 API 首次请求巨慢现象用户第一次访问页面登录要等 10 秒以上后续请求秒开。原因IIS 应用池默认“闲置超时”为 20 分钟超时后进程被回收。下次请求来时IIS 要重新加载 .NET 运行时、初始化 Kestrel耗时很长。修复技巧应用池 → 高级设置 → “闲置超时分钟” 改为 0永不超时同时“启动模式”改为“始终运行”“预加载启用”设为 True。这样应用池启动时就加载应用永远不休眠。坑二Vue Router history 模式在 IE11 下白屏现象Chrome 正常IE11 打开首页白屏Console 报错Object doesnt support property or method assign。原因Vue Router 4.x 默认使用 Object.assignIE11 不支持。修复技巧在 Vue 项目根目录新建 vue.config.js添加 babel polyfillmodule.exports { transpileDependencies: [vue-router], configureWebpack: { resolve: { fallback: { crypto: false, stream: false, os: false, util: false } } } }并在 main.js 顶部引入import babel/polyfill然后npm install --save-dev babel/polyfill。这是兼容 IE11 的最小代价方案。坑三Linux 服务器上 Nginx 代理 ASP.NET Core返回 502 且日志无记录现象Ubuntu 上部署Nginx 日志只有 502Kestrel 日志为空。原因Linux 的 SELinux 或 AppArmor 限制了 Nginx 访问 127.0.0.1:5000。修复技巧Ubuntu# 检查 AppArmor 状态 sudo aa-status # 临时禁用测试用 sudo systemctl stop apparmor # 永久禁用生产环境慎用 sudo systemctl disable apparmor # 或者给 Nginx 添加网络访问权限 sudo nano /etc/apparmor.d/usr.sbin.nginx # 在文件末尾添加 # network inet stream, # network inet6 stream, sudo systemctl reload apparmor5.3 生产环境必须开启的三项监控部署不是终点而是运维的起点。这三个监控点能帮你提前 80% 的故障Nginx 访问日志分析每天用 awk 统计 4xx/5xx 状态码占比。如果 /api/login 的 400 错误突增可能是前端传参格式错误如果 /api/data 的 429 突增说明需要加限流。IIS stdout 日志轮转在 web.config 的 aspNetCore 节点里添加stdoutLogEnabledtrue和stdoutLogFile.\logs\stdout并用 PowerShell 脚本每日压缩旧日志Get-ChildItem C:\deploy\backend\logs\stdout_* | Where-Object {$_.LastWriteTime -lt (Get-Date).AddDays(-7)} | ForEach-Object { Compress-Archive $_.FullName $($_.DirectoryName)\$($_.BaseName).zip; Remove-Item $_.FullName }前端 Sentry 错误监控在 Vue 项目里集成 Sentryhttps://docs.sentry.io/platforms/javascript/guides/vue/捕获 JS 运行时错误、Promise reject、Vue 异常。它能告诉你用户在哪个页面、什么机型、什么网络环境下遇到了什么错误比客服电话反馈快十倍。最后再分享一个小技巧每次发布新版本都在 dist 文件夹里生成一个 version.json 文件内容为{ version: 1.2.3, buildTime: 2023-10-15T14:22:33Z, commit: a1b2c3d }然后在 Vue 的 mounted 钩子中 fetch 这个文件把版本号显示在页面 footer。这样客户说“功能不对”你一眼就能确认他用的是不是最新版省去无数沟通成本。 Vue+ASP.NET前后端分离项目生产部署实战指南
1. 这不是“配环境”是交付一个能跑在生产服务器上的完整系统Vue ASP.NET Web API 前后端分离项目发布部署这八个字背后藏着的不是“点几下鼠标就能上线”的幻觉而是一整套工程闭环前端构建产物如何与后端服务协同、静态资源路径怎么不被404吞掉、跨域问题在生产环境里根本不存在——因为它压根不该出现在生产环境里、token怎么从登录态安全流转到每次请求头、IIS或Kestrel怎么扛住真实用户并发、甚至一个favicon.ico 404都可能暴露你的目录结构。我做过27个上线项目其中19个卡在部署环节不是代码写错了而是对“发布”二字的理解停留在本地 npm run build 和 dotnet publish 的机械执行上。真正决定项目能否稳定运行的恰恰是那几十行配置、几个路径参数、一次反向代理的映射规则以及你有没有在凌晨三点盯着 IIS 日志查500错误时突然意识到 web.config 里 的 customHeaders 写错了顺序。这个过程适合三类人刚用 Vue CLI 搭完登录页、正准备把项目交给客户验收的前端同学接手了前端打包产物、却不知道该往 IIS 哪个文件夹扔的 .NET 开发者还有那些被“前后端分离”概念绕晕、以为只要接口通了就万事大吉的项目经理。它不讲 Vue 的响应式原理也不深挖 ASP.NET Core 的中间件管道只聚焦一件事让 build 出来的 dist 文件夹和 publish 出来的 dll 文件在 Windows Server 或 Linux 服务器上像在你本机 localhost:8080 localhost:5000 那样稳稳当当地跑起来并且扛得住真实流量。接下来所有内容全部来自我踩过的坑、改过的配置、重装过三次的 IIS、以及客户服务器上那段被反复注释又取消注释的 nginx location 块。2. 整体设计思路为什么必须拆成“前端静态托管”“后端API服务”两层2.1 前后端分离的本质不是技术选型而是职责边界很多人误以为“用了 Vue 和 Web API 就叫前后端分离”其实这只是表象。真正的分离是把“谁负责呈现页面”和“谁负责提供数据”彻底解耦。Vue 应用编译后是一堆 HTML、CSS、JS 和图片它们不需要服务器执行任何逻辑只需要被 HTTP 服务器原样返回给浏览器而 ASP.NET Web API 是一个独立的进程监听某个端口比如 5000只做一件事接收 HTTP 请求、校验 token、查数据库、返回 JSON。这两者之间不应该存在任何代码级依赖也不应该共享同一个进程或应用池。我见过最典型的反模式是把 Vue 的 dist 文件夹直接塞进 ASP.NET MVC 的 Views 目录再用 Controller 返回一个空 View靠 script 标签加载 index.js —— 这看起来像分离实则把前端构建产物变成了后端项目的“资源文件”一旦要升级 Vue 版本或更换构建工具就得重新编译整个 .NET 解决方案完全违背了分离的初衷。所以部署的第一步就是明确物理隔离前端走 Nginx/IIS 静态文件托管后端走 Kestrel/IIS 反向代理或独立进程。这种设计带来三个硬性好处发布解耦前端团队可以独立发布新版本只需替换 dist 文件夹内容不影响后端服务进程后端团队升级框架或修复接口前端无需重新构建。性能优化静态资源由擅长处理高并发小文件的 Web 服务器如 Nginx直接返回不经过 .NET 运行时首屏加载速度提升 30%~60%API 请求则由 Kestrel 这种高性能 HTTP 服务器专注处理。安全加固前端资源可配置强缓存Cache-Control: public, max-age31536000减少重复请求后端 API 则可通过 IIS 的 IP 限制、请求过滤等模块做第一道防线两者策略互不干扰。2.2 为什么不能直接用 Vue DevServer 代理到后端生产环境没有 devServerVue CLI 的 vue.config.js 里写个 devServer.proxy本地开发时确实方便。但这是开发阶段的“模拟”本质是 webpack-dev-server 启动了一个中间层把 /api/ 开头的请求转发给 http://localhost:5000。这个 proxy 在 build 之后就彻底消失不会打包进任何产物里。很多新手把本地能跑通的代码直接扔到服务器发现所有接口 404第一反应是“后端没启动”其实是前端页面里的 fetch(/api/login) 这个路径在生产环境里根本没人监听——因为浏览器直接向当前域名发起请求而你的 Nginx 或 IIS 根本没配置这条路由的转发规则。正确的做法是前端代码里所有 API 请求必须使用绝对路径或相对路径且该路径需与生产环境的反向代理规则严格匹配。例如约定所有 API 路径以 /api/ 开头那么 Nginx 配置就必须把 /api/ 开头的请求无条件转发到 http://127.0.0.1:5000同时前端 axios 的 baseURL 就设为 /api/而不是 http://localhost:5000/api/。这样无论前端部署在 www.example.com 还是 app.example.com只要 Nginx 规则一致请求就能精准抵达后端。2.3 ASP.NET Web API 的宿主选择Kestrel vs IIS不是二选一而是组合拳ASP.NET Core 官方文档说 Kestrel 是跨平台、高性能的 Web 服务器IIS 是 Windows 上的传统 Web 服务器。但实际部署中Kestrel 绝不单独暴露在公网。原因很现实Kestrel 缺少企业级功能比如请求压缩、SSL 卸载、IP 白名单、URL 重写、负载均衡支持。它就像一辆顶级超跑引擎强悍但没有空调、没有安全气囊、不能上高速——必须套在一个更稳健的“外壳”里。所以标准架构是Kestrel 作为应用内嵌服务器监听 localhost:5000或任意内部端口只接受来自本机的请求IIS或 Nginx作为反向代理监听 80/443 端口接收所有外部请求再根据规则把 /api/ 转发给 Kestrel。IIS 在这里不是“宿主”而是“网关”。这种组合既保留了 Kestrel 的高性能又利用了 IIS 成熟的管理界面、日志系统和安全模块。我在客户现场遇到过一次事故某同事图省事把 Kestrel 直接绑定到 0.0.0.0:5000 并开放防火墙端口结果第二天就被扫描器打爆了内存因为 Kestrel 默认不启用请求体大小限制恶意构造的超大 POST 请求直接拖垮进程。而换成 IIS 反向代理后我们能在 IIS 层面设置 requestLimits瞬间解决问题。3. 核心细节解析从构建到上线的每一步关键操作3.1 Vue 项目构建前的必改项public/index.html 与 router 的 base 配置Vue CLI 构建时默认把所有静态资源路径写成相对路径如 ./js/app.js。如果前端部署在域名根路径https://example.com/这没问题但如果部署在子路径https://example.com/admin/就会出现 JS/CSS 加载 404。根源在于浏览器解析 ./js/app.js 时会以当前页面 URL 为基准即 https://example.com/admin/ → https://example.com/admin/js/app.js。而实际文件在 https://example.com/admin/dist/js/app.js。解决方案分两步第一步修改 vue.config.js 中的 publicPath// vue.config.js module.exports { // 如果部署在根路径设为 / // 如果部署在子路径比如 https://example.com/myapp/则设为 /myapp/ publicPath: process.env.NODE_ENV production ? /admin/ : /, outputDir: dist, assetsDir: static }这个 publicPath 会注入到 index.html 的script和link标签中确保资源路径正确。第二步如果用了 Vue Router 的 history 模式即 URL 不带 #必须配置 router 的 base// router/index.js const router new VueRouter({ mode: history, base: process.env.NODE_ENV production ? /admin/ : /, routes: [...] })base 值必须与 publicPath 完全一致。否则用户直接访问 https://example.com/admin/user/1 时Nginx 会把请求转发给前端静态服务器但前端 router 找不到匹配的路由显示空白页。这是因为 history 模式下router 初始化时会读取当前 URL 的 pathname/admin/user/1然后去 routes 里匹配如果 base 设为 /它会尝试匹配 /user/1自然失败。提示如果你不确定部署路径可以在构建后手动编辑 dist/index.html把script src/js/app.js改成script src/admin/js/app.js但这只是临时救急长期维护必须靠配置驱动。3.2 ASP.NET Web API 的跨域CORS配置开发期开生产期关CORS 是开发阶段的“便利贴”不是生产环境的“安全门”。本地开发时Vue 运行在 http://localhost:8080Web API 在 http://localhost:5000浏览器同源策略会拦截请求所以我们在 Startup.cs 里加// Startup.cs public void ConfigureServices(IServiceCollection services) { services.AddCors(options { options.AddPolicy(AllowAll, builder { builder.AllowAnyOrigin() // 允许所有来源 .AllowAnyMethod() .AllowAnyHeader(); }); }); } public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { app.UseCors(AllowAll); // 启用 CORS }这段代码在开发时救命但在生产环境必须删除或禁用。原因有二一是 AllowAnyOrigin() 会返回 Access-Control-Allow-Origin: *但若响应头包含 credentials如 cookie 或 Authorization header浏览器会拒绝该响应二是它完全放弃了来源控制任何网站都能调用你的 API等于把数据库钥匙挂在门口。生产环境的正确做法是在反向代理层Nginx/IIS统一处理跨域后端代码里彻底移除 CORS 配置。因为前端和后端在生产环境共享同一个域名如 https://example.com浏览器认为它们同源根本不会触发跨域检查。所有 /api/ 请求都是从 https://example.com 发起被 Nginx 拦截并转发给后端响应再原路返回全程无跨域。我曾帮一个金融客户排查过 API 响应慢的问题最后发现是后端启用了 CORS每次请求都多了一次 PreflightOPTIONS预检而预检响应里又包含了大量不必要的 headers白白消耗了 200ms。关掉 CORS 后接口平均耗时下降 15%。3.3 Token 处理的两种落地方式localStorage vs HttpOnly CookieVue 前端登录后token 怎么存、怎么发直接影响安全性。常见方案有两种方案一存 localStorage每次请求手动添加 Authorization header// 登录成功后 localStorage.setItem(token, response.data.token) // axios 请求拦截器 axios.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config })优点简单直接JWT token 可以轻松解析 payload 查看用户信息缺点XSS 攻击可窃取 token因为 localStorage 可被 JavaScript 读取。方案二后端 Set-Cookie 返回 HttpOnly Cookie前端无需操作// 登录成功后 var cookieOptions new CookieOptions { HttpOnly true, // JS 无法读取 Secure true, // 仅 HTTPS 传输 SameSite SameSiteMode.Strict, Expires DateTime.UtcNow.AddDays(7) }; Response.Cookies.Append(auth_token, token, cookieOptions);前端完全不用管 token浏览器自动在每次请求中携带 Cookie。后端用 [Authorize] 特性自动验证。优点防 XSStoken 不在前端内存中缺点需要处理 CSRF可用 SameSiteStrict 缓解且 JWT 优势无状态、自包含被弱化因为 token 存在服务端 session 或 Redis 中。我的建议是内部管理系统用方案二面向公众的网站用方案一 前端加密存储如用 crypto-js AES 加密后再存 localStorage。前者更重安全后者更重灵活性。无论哪种都必须在后端 API 的响应头中明确设置 Access-Control-Allow-Credentials: true并在前端 axios 配置 withCredentials: true否则 Cookie 不会发送。3.4 IIS 部署 ASP.NET Web API 的五个致命细节IIS 部署不是把 publish 文件夹复制过去就完事。以下是我在 Windows Server 2016/2019 上踩过的五个必改点应用池 .NET CLR 版本必须设为“无托管代码”ASP.NET Core 应用是独立进程dotnet.exe不依赖 IIS 的 .NET 运行时。如果应用池设为 .NET CLR v4.0IIS 会试图用 w3wp.exe 加载你的 dll导致 502.5 错误。正确设置应用池 → 高级设置 → .NET CLR 版本 → 无托管代码。应用池“启用 32 位应用程序”必须与你的 SDK 匹配如果你用 x64 SDK publish应用池必须禁用 32 位反之亦然。错误会导致“找不到 dll”或“BadImageFormatException”。检查方法命令行运行dotnet --list-runtimes看输出的是 Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 还是 [C:\Program Files (x86)\dotnet\shared...]。web.config 必须存在且内容正确publish 时会自动生成 web.config但有时会被覆盖。核心内容如下?xml version1.0 encodingutf-8? configuration system.webServer handlers add nameaspNetCore path* verb* modulesAspNetCoreModuleV2 resourceTypeUnspecified / /handlers aspNetCore processPathdotnet arguments.\YourApi.dll stdoutLogEnabledtrue stdoutLogFile.\logs\stdout hostingModelinprocess environmentVariables environmentVariable nameASPNETCORE_ENVIRONMENT valueProduction / /environmentVariables /aspNetCore /system.webServer /configuration关键点processPathdotnet不是 yourapp.exehostingModelinprocess推荐性能更好stdoutLogEnabledtrue开启日志排错必备。站点绑定必须包含 HTTPS且 SSL 证书已绑定即使前端用 HTTPAPI 也必须走 HTTPS。否则浏览器会阻止混合内容HTTP 页面加载 HTTPS 资源可行但 HTTPS 页面加载 HTTP API 会被拦截。在 IIS 站点 → 绑定 → 添加 → 类型选 https端口 443SSL 证书选已安装的证书。Windows 防火墙必须放行端口Kestrel 默认监听 localhost:5000但 IIS 反向代理需要访问这个端口。防火墙默认阻止本地回环访问。解决高级安全 Windows 防火墙 → 入站规则 → 新建规则 → 端口 → TCP 5000 → 允许连接 → 作用域设为“本地回环”。注意IIS 日志默认在 C:\inetpub\logs\LogFiles\W3SVC1但 stdout 日志在你 publish 文件夹下的 logs 目录。500 错误时先看 stdout_log.txt里面会有详细的异常堆栈比 IIS 日志有用十倍。4. 实操过程从零开始部署一个可运行的 demo4.1 准备工作环境清单与权限确认在动手前必须确认以下五项缺一不可服务器操作系统Windows Server 2016 或更高版本IIS 部署或 Ubuntu 20.04Nginx systemd 部署。本文以 Windows 为例。已安装软件IIS角色服务里勾选“Web 服务器(IIS)”、“.NET Extensibility 4.8”、“HTTP 响应标头”ASP.NET Core Runtime 6.0下载地址https://dotnet.microsoft.com/download/dotnet/6.0选 Runtime不是 SDKURL Rewrite ModuleIIS 反向代理必需下载地址https://www.iis.net/downloads/microsoft/url-rewrite文件权限publish 文件夹需赋予 IIS_IUSRS 用户“读取 执行”权限logs 文件夹需额外赋予“写入”权限否则 stdout 日志无法生成。域名与证书已申请好域名如 api.example.com并安装好 SSL 证书到服务器证书存储区。网络权限服务器 80/443 端口已开放云服务器需检查安全组5000 端口仅限本机访问防火墙已按 3.4 节配置。我建议新建一个专用 Windows 用户如 deployer将其加入 IIS_IUSRS 组并用此用户登录远程桌面操作避免用 Administrator 账户引发权限混乱。4.2 Vue 前端部署Nginx 静态托管实战虽然标题是 ASP.NET但前端部署同样关键。我们用 Nginx轻量、稳定、配置直观托管 Vue 构建产物下载 Nginx for Windowshttps://nginx.org/en/download.html解压到 C:\nginx。修改 conf/nginx.confworker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 配置前端站点 server { listen 80; server_name www.example.com; # 根路径指向 dist 文件夹 location / { root C:/deploy/frontend/dist; index index.html; try_files $uri $uri/ /index.html; # history 模式必备 } # API 请求全部转发给后端 location /api/ { proxy_pass http://127.0.0.1:5000/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } # 配置 HTTPS 站点可选但强烈推荐 server { listen 443 ssl; server_name www.example.com; ssl_certificate C:/certs/example.com.crt; ssl_certificate_key C:/certs/example.com.key; location / { root C:/deploy/frontend/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass https://127.0.0.1:5001/; # 后端也走 HTTPS # ... 其他 proxy_set_header 同上 } } }关键点解释try_files $uri $uri/ /index.html确保 history 模式下用户刷新 /user/1 页面时Nginx 不返回 404而是返回 index.html由 Vue Router 处理路由。proxy_pass http://127.0.0.1:5000/末尾的/至关重要它表示“去掉 /api/ 前缀再转发”。例如请求 /api/login会被转发为 http://127.0.0.1:5000/login。如果写成proxy_pass http://127.0.0.1:5000;无斜杠则转发为 http://127.0.0.1:5000/api/login后端控制器收不到。启动 Nginx双击 nginx.exe或命令行start nginx。检查是否运行任务管理器 → 服务 → nginx.exe 进程是否存在。测试前端浏览器访问 http://www.example.com应看到 Vue 页面F12 查看 Network确认 js/css 加载正常且无 404。4.3 ASP.NET Web API 部署IIS 反向代理全流程现在部署后端在 Visual Studio 中右键 Web API 项目 → 发布 → 选择“文件夹” → 目标位置设为 C:\deploy\backend\publish。确保发布设置正确配置Release目标框架net6.0部署模式框架依赖Framework-dependent目标运行时win-x64与服务器 CPU 架构一致勾选“删除目标文件夹中的现有文件”复制 publish 文件夹全部内容到 C:\deploy\backend\。打开 IIS 管理器 → 左侧“连接”窗格 → 右键“网站” → “添加网站”网站名称MyApi物理路径C:\deploy\backend\绑定类型 httpsIP 地址全部未分配端口 443主机名 api.example.comSSL 证书选已安装的证书配置反向代理URL Rewrite选中刚创建的 MyApi 网站 → 双击“URL 重写”点击右侧“添加规则” → 选择“空白规则”名称Proxy to Kestrel匹配 URL请求的 URL → 使用正则表达式 → 模式^(.*)$条件无操作重写 → 重写 URLhttp://127.0.0.1:5000/{R:1} → 附加查询字符串勾选 → 停止处理后续规则勾选点击“应用”启动网站右键 MyApi → “启动”。检查应用池是否也处于“正在运行”状态。测试 API浏览器访问 https://api.example.com/health假设你有一个 HealthController应返回 {status:Healthy}用 Postman 调用 https://api.example.com/api/login应返回 token。实操心得IIS 的 URL Rewrite 规则比 Nginx 的 location 更容易出错。常见错误是“重写 URL”里写了 http://localhost:5000/{R:1}但 localhost 在 IIS 进程里解析失败必须用 127.0.0.1。另外规则必须放在“网站”级别不能放在“应用程序”级别否则不生效。4.4 前后端联调与最终验证三步确认法部署完成后必须进行三步验证缺一不可第一步前端独立验证打开浏览器开发者工具 → Network 标签 → 刷新页面。观察所有 JS/CSS/图片请求状态码为 200Size 列显示文件大小非 0没有 404 请求特别是 favicon.ico、manifest.json页面渲染正常Vue Devtools 显示组件树。第二步API 独立验证用 curl 或 Postman 直接请求后端curl -X POST https://api.example.com/api/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}预期返回 200 和 token。如果返回 500立刻查看 C:\deploy\backend\logs\stdout_*.log找第一行异常信息。第三步全链路验证在 Vue 页面上点击登录按钮。F12 查看 Network登录请求 URL 是 https://www.example.com/api/login注意是 www 域名不是 api请求 Method 是 POSTStatus 是 200Response Headers 里有 Set-Cookie如果用了 Cookie 方案或直接返回 token 字段后续请求如获取用户信息的 Request Headers 里有 Authorization: Bearer xxxxx。如果第三步失败90% 的原因是前端 baseURL 设错了或者 Nginx 的 location /api/ 规则没生效。此时不要猜直接在 Nginx 日志logs/access.log里搜索 “api/login”看是否有记录再检查 IIS 的 Failed Request Tracing开启后能捕获完整的请求生命周期。5. 常见问题与排查技巧实录那些凌晨三点的救火记录5.1 问题速查表高频故障与一键定位现象可能原因快速定位方法解决方案前端页面白屏Console 报错Failed to load resource: net::ERR_CONNECTION_REFUSEDNginx 未运行或 80 端口被占用命令行netstat -ano | findstr :80看 PID 对应哪个进程重启 Nginx或taskkill /PID {PID} /F杀掉占用进程API 请求返回 502 Bad GatewayIIS 反向代理未连通 Kestrel或 Kestrel 进程崩溃查看 IIS 应用池状态检查 C:\deploy\backend\logs\stdout_*.log 最后一行重启应用池确认 publish 文件夹里有 YourApi.dll 和 web.config登录成功但后续请求 401 Unauthorizedtoken 未正确添加到请求头或后端 JWT 验证失败F12 → Network → 点击一个 401 请求 → Headers → 看 Request Headers 里是否有 Authorization前端检查 axios 拦截器后端检查 Startup.cs 的 AddJwtBearer 配置Issuer 和 Audience 是否与 token 里的一致页面样式错乱字体图标显示为方块publicPath 配置错误导致 CSS 中的字体路径 404F12 → Network → Filter 输入.woff看是否 404修改 vue.config.js 的 publicPath确保与部署路径一致构建后检查 dist/css/app.css 里的 url() 路径HTTPS 页面加载 HTTP API 被浏览器拦截前端 baseURL 写了 http://或 Nginx proxy_pass 用了 http://F12 → Console看是否有Mixed Content警告前端 baseURL 改为/api/Nginx proxy_pass 改为https://127.0.0.1:5001/后端 Kestrel 启用 HTTPS5.2 我踩过的三个典型坑及独家修复技巧坑一IIS 应用池“闲置超时”导致 API 首次请求巨慢现象用户第一次访问页面登录要等 10 秒以上后续请求秒开。原因IIS 应用池默认“闲置超时”为 20 分钟超时后进程被回收。下次请求来时IIS 要重新加载 .NET 运行时、初始化 Kestrel耗时很长。修复技巧应用池 → 高级设置 → “闲置超时分钟” 改为 0永不超时同时“启动模式”改为“始终运行”“预加载启用”设为 True。这样应用池启动时就加载应用永远不休眠。坑二Vue Router history 模式在 IE11 下白屏现象Chrome 正常IE11 打开首页白屏Console 报错Object doesnt support property or method assign。原因Vue Router 4.x 默认使用 Object.assignIE11 不支持。修复技巧在 Vue 项目根目录新建 vue.config.js添加 babel polyfillmodule.exports { transpileDependencies: [vue-router], configureWebpack: { resolve: { fallback: { crypto: false, stream: false, os: false, util: false } } } }并在 main.js 顶部引入import babel/polyfill然后npm install --save-dev babel/polyfill。这是兼容 IE11 的最小代价方案。坑三Linux 服务器上 Nginx 代理 ASP.NET Core返回 502 且日志无记录现象Ubuntu 上部署Nginx 日志只有 502Kestrel 日志为空。原因Linux 的 SELinux 或 AppArmor 限制了 Nginx 访问 127.0.0.1:5000。修复技巧Ubuntu# 检查 AppArmor 状态 sudo aa-status # 临时禁用测试用 sudo systemctl stop apparmor # 永久禁用生产环境慎用 sudo systemctl disable apparmor # 或者给 Nginx 添加网络访问权限 sudo nano /etc/apparmor.d/usr.sbin.nginx # 在文件末尾添加 # network inet stream, # network inet6 stream, sudo systemctl reload apparmor5.3 生产环境必须开启的三项监控部署不是终点而是运维的起点。这三个监控点能帮你提前 80% 的故障Nginx 访问日志分析每天用 awk 统计 4xx/5xx 状态码占比。如果 /api/login 的 400 错误突增可能是前端传参格式错误如果 /api/data 的 429 突增说明需要加限流。IIS stdout 日志轮转在 web.config 的 aspNetCore 节点里添加stdoutLogEnabledtrue和stdoutLogFile.\logs\stdout并用 PowerShell 脚本每日压缩旧日志Get-ChildItem C:\deploy\backend\logs\stdout_* | Where-Object {$_.LastWriteTime -lt (Get-Date).AddDays(-7)} | ForEach-Object { Compress-Archive $_.FullName $($_.DirectoryName)\$($_.BaseName).zip; Remove-Item $_.FullName }前端 Sentry 错误监控在 Vue 项目里集成 Sentryhttps://docs.sentry.io/platforms/javascript/guides/vue/捕获 JS 运行时错误、Promise reject、Vue 异常。它能告诉你用户在哪个页面、什么机型、什么网络环境下遇到了什么错误比客服电话反馈快十倍。最后再分享一个小技巧每次发布新版本都在 dist 文件夹里生成一个 version.json 文件内容为{ version: 1.2.3, buildTime: 2023-10-15T14:22:33Z, commit: a1b2c3d }然后在 Vue 的 mounted 钩子中 fetch 这个文件把版本号显示在页面 footer。这样客户说“功能不对”你一眼就能确认他用的是不是最新版省去无数沟通成本。