什么是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<t></t>模式 旧系统用
Web.config的
<appsettings></appsettings>，新系统默认读
appsettings.json—— 不要硬编码路径，用
IConfiguration抽象统一加载，必要时加自定义Provider从Web.config读取 前端AJAX请求若带
withCredentials: true，而新旧API部署在不同子域（如
old.example.com/
new.example.com），必须显式设置
Access-Control-Allow-Origin为具体域名，不能用
*
真正的难点不在写新代码，而在定义清楚「哪天之后，这个URL路径不再转发给旧系统」——这需要业务方签字确认，而不是开发拍板。
