Strangler Fig模式是一种架构迁移策略，指在C#项目中用ASP.NET Core新模块逐步替代ASP.NET Framework旧系统，通过反向代理路由共存于同一域名，解耦身份认证、数据访问与配置管理，避免一步重写风险。
什么是Strangler Fig模式在C#中的实际含义
Strangler Fig不是C#语言特性，也不是.NET库里的某个类或接口，它是一种架构迁移策略——用新模块逐步“绞杀”旧系统。在C#项目中，它表现为：新功能用ASP.NET Core写，老功能仍跑在ASP.NET Framework（甚至Web Forms）上，两者共存于同一域名，靠反向代理或网关分流。
关键判断点：如果你的遗留系统是单体、紧耦合、测试覆盖率低、不敢动核心流程，又必须上线新需求，Strangler Fig就是当前最可行的路径；想一步重写，基本等于重蹈覆辙。
如何让ASP.NET Core和旧.NET Framework共存于同一入口
核心在于请求路由不交给任一后端全权处理，而是前置一层决策逻辑。常见做法是用Nginx或IIS URL重写规则做路径分流：
-
/api/v2/、/admin/→ 转发到新的ASP.NET Core站点（比如https://new-api.example.com） -
/legacy/*、/webforms/→ 保持指向旧IIS应用池 - 静态资源（
.js、.css）统一由CDN或Nginx缓存，避免跨域和版本混乱
注意：不要用Response.Redirect硬跳转，那会暴露内部路径、破坏单页体验；必须用反向代理（proxy_pass 或 IIS ARR）维持Host头和Cookie域一致。
C#代码层如何解耦新旧系统间的数据与身份依赖
旧系统常把用户信息塞进Session、HttpContext.Current.Items，而ASP.NET Core默认不共享这些。直接复用会出错：
常见错误现象：NullReferenceException 在尝试读取HttpContext.Session，或User.Identity.Name为空
- 身份认证统一走JWT或Cookie共享方案：旧系统生成
FormsAuthentication.SetAuthCookie后，新系统用CookieAuthenticationDefaults.AuthenticationScheme验证同一.ASPXAUTHCookie（需配置Cookie.SameSite = SameSiteMode.None且HTTPS） - 数据库层面不急于拆分：初期共用同一SQL Server库，但新模块只读写自己新建的表，旧模块继续用原表；用视图或存储过程封装过渡逻辑
- 避免在新代码里调用
System.Web命名空间下的任何类型（如HttpServerUtility），它们在.NET Core中不存在
迁移过程中最容易被忽略的三个技术断点
很多团队卡在这几步，不是技术不行，而是没提前压测或约定边界：
-
HttpContext.Current在.NET Core中彻底移除，所有依赖它的日志、权限、上下文追踪代码必须重写为IHttpContextAccessor+AsyncLocal模式 - 旧系统用
Web.config的appsettings.json—— 不要硬编码路径，用IConfiguration抽象统一加载，必要时加自定义Provider从Web.config读取 - 前端AJAX请求若带
withCredentials: true，而新旧API部署在不同子域（如old.example.com/new.example.com），必须显式设置Access-Control-Allow-Origin为具体域名，不能用*
真正的难点不在写新代码，而在定义清楚「哪天之后，这个URL路径不再转发给旧系统」——这需要业务方签字确认，而不是开发拍板。
