发布前必须检查web.config无开发环境硬编码，确保IIS应用程序池.NET版本匹配，启用匿名认证并配置默认文档，使用文件系统发布而非FTP，且安装对应ASP.NET Core Runtime Hosting Bundle。
发布前必须确认 web.config 里没硬编码开发环境配置
很多人在本地跑通就直接打包，结果部署到 iis 后 500 错误、连接字符串连错库、日志写不进路径——八成是 web.config 里还留着 localhost、integrated security=true 或绝对路径 c:\temp\log.txt。asp.net（尤其 .net framework）不会自动替换这些，得手动改或用配置转换。
实操建议：
- 检查
<connectionstrings></connectionstrings>和<appsettings></appsettings>，把开发用的值换成 IIS 服务器能访问的地址和凭据 - 如果用了 Web.config 转换（如
Web.Release.config），确保发布时选的是Release配置，且转换规则已生效（可右键项目 → “预览转换”验证） - 避免在配置里写
~\或Server.MapPath之外的相对路径，IIS 应用程序池工作目录未必等于站点物理路径
用 Visual Studio 发布时，“文件系统”目标比“FTP”更可控
直接点“发布” → 选“FTP”看着省事，但超时、权限、被动模式、字符编码问题一堆，尤其内网 IIS 根本不需要走 FTP。真要稳定，选“文件系统”导出到本地文件夹，再手动拷过去，反而快且可审计。
实操建议：
- 发布方法选
文件系统，目标路径设为一个干净空文件夹（如D:\publish-output） - 发布配置选
Release，勾选删除目标位置中不存在的文件（防旧 DLL 残留） - 注意
配置文件转换是否启用 —— 如果没开，Web.config不会按配置名自动替换 - 生成后检查输出目录有没有
bin\*.dll、web.config、视图文件（.cshtml），缺任何一项都可能 404 或编译失败
IIS 上应用程序池 .NET 版本必须和项目匹配
常见错误现象：HTTP Error 500.19 - Internal Server Error，错误代码 0x8007000d，或者页面空白返回 500 但没日志——大概率是应用程序池托管管道模式或 .NET CLR 版本设错了。
实操建议：
- ASP.NET Core 项目：应用程序池 .NET CLR 版本选
无托管代码，且必须用反向代理（IIS 作为前端，Kestrel 托管应用），不能直接跑 in-process - ASP.NET MVC / Web Forms（.NET Framework）：CLR 版本严格对应项目目标框架，比如项目是
.NET Framework 4.7.2，池就得设成v4.0（不是 v2.0，也不是 “不托管”） - 托管管道模式：传统 ASP.NET 用
集成模式；若遇到奇怪的模块加载失败（比如HttpModule不触发），可临时切到经典排查，但别长期用
部署后访问 403/404，先看 IIS 的“默认文档”和匿名认证
页面打不开，不是代码问题，而是 IIS 根本没把请求交给 ASP.NET 处理。最常踩的坑是：没开匿名认证、没配默认文档、或静态文件处理把 .aspx/.cshtml 拦截了。
实操建议：
- 进 IIS 管理器 → 站点 → “默认文档”，确认列表里有
default.aspx（Web Forms）或index.cshtml（MVC 默认路由入口不依赖此，但根路径访问需要） - “身份验证”里，
匿名身份验证必须启用（除非你明确用 Windows 身份验证）；Windows 身份验证可关可开，但开了就得同步配好用户权限 - 检查“处理程序映射”，确认
*.aspx、*.asmx等扩展名绑定了正确的 ISAPI 模块（Framework 项目）或aspNetCore模块（Core 项目） - 如果部署的是 ASP.NET Core，还要确认服务器装了对应版本的
ASP.NET Core Runtime Hosting Bundle，光装 SDK 不行
真正麻烦的往往不是打包动作本身，而是配置项散落在 VS 发布设置、web.config、IIS 管理器、Windows 权限、防火墙多个地方，改一处漏一处。上线前最好拿一台干净测试机，从新建站点开始重走一遍，别复用旧配置。
