debug="true"会强制启用JIT调试、生成.pdb、禁用代码优化并单独编译页面，仅限开发环境使用；生产环境必须设为false，否则性能严重下降且存在安全风险。
debug="true" 会让 ASP.NET 编译器保留调试符号和禁用优化
ASP.NET 运行时看到 debug="true"，会强制启用 JIT 调试支持、生成 .pdb 文件、跳过代码优化（比如内联函数、死代码消除），同时允许 Visual Studio 附加调试器并命中断点。这不是“开个开关就能调试”，而是整套编译行为的切换。
- 只在开发机或测试环境设为
true；生产环境必须是false，否则内存占用高、启动慢、JIT 编译耗时长 -
debug="true"会隐式关闭batch="true"（即使你显式写了），导致每个 .aspx 页面单独编译，页面首次访问延迟明显升高 - IIS 中若启用了“预编译”（如
aspnet_compiler工具），debug="true"仍会影响运行时行为——比如HttpContext.Current.Trace日志级别、错误页是否显示堆栈
system.web/compilation 节点下还有哪些关键配置影响调试体验
仅改 debug 不够，<compilation></compilation> 下几个属性相互牵制，漏掉一个就可能让断点失效或报错不清晰。
-
targetFramework必须与项目实际框架一致，比如写成"4.7.2"但项目是 .NET Framework 4.8，会导致System.Web.HttpCompileException，且错误信息里不会明说版本冲突 -
batch="false"强制单文件编译，适合调试时快速定位某一页的问题，但会显著拖慢整个站点冷启动速度 -
tempDirectory指向的路径需有 IIS_IUSRS 写权限，否则debug="true"时生成.pdb失败，VS 提示“源代码与原始版本不匹配”
为什么本地能断点，部署到 IIS 就不进断点
常见不是代码问题，而是 web.config 或 IIS 配置没对齐。VS 调试依赖符号文件 + 匹配的二进制 + 启用调试的运行时状态，三者缺一不可。
- 检查目标服务器上
web.config的debug值是否真为"true"（注意引号是英文双引号，且没有拼写成deubg） - IIS 应用池的 .NET 版本必须与
targetFramework兼容，比如targetFramework="4.8"但应用池是 “No Managed Code”，断点必然无效 - 发布时若勾选了 “删除所有现有文件”，而
bin/下残留旧版.pdb，VS 可能加载错符号——建议清空目标bin/和Temporary ASP.NET Files/目录再重试
debug="false" 时依然看到详细错误页？别信表象
很多人以为把 debug="false" 就安全了，结果浏览器还是爆出完整堆栈。这通常是因为 <customerrors></customerrors> 或 IIS 错误页配置没同步关掉。
-
debug="false"只控制编译行为，不控制错误页面展示逻辑；必须额外确认<system.web><customerrors mode="On" defaultredirect="Error.aspx"></customerrors></system.web> - IIS 级别的错误页（如 500.19）优先级高于
customErrors，若 IIS 设置了“详细错误”，debug="false"也拦不住 - Web API 项目中，
debug="false"不影响HttpResponseException的响应体内容，需靠GlobalConfiguration.Configuration.IncludeErrorDetailPolicy控制
最常被忽略的是：debug="true" 在 web.config 里被多个配置节覆盖（比如 <location path="api">...</location> 单独设了 debug="false"），实际生效的不是根节点那个值。查的时候得一层层看 location 匹配路径和继承规则。
