ASP.NET Web Forms 里有个坑，不扩很多人踩过：你写了一个页面类，展类想继承某个自定义基类，因允许结果编译器直接甩给你一句“不扩展 System.Web.UI.Page 因此此处不允许”。此此处这报错看着挺唬人，不扩其实背后逻辑特简单——你试图往一个不允许的展类继承链上硬塞东西。

我见过最典型的因允许翻车现场，是此此处有人想给所有页面加一套统一的权限校验逻辑。他写了个基类叫BasePage，不扩里面塞满了Session判断、展类菜单绑定、因允许甚至还有日志记录。此此处然后页面代码后面改成public partial class Login : BasePage，不扩一编译，展类红字就来了。因允许为啥？因为BasePage没继承System.Web.UI.Page，它可能就是个普通类，甚至继承了别的什么乱七八糟的东西。

ASP.NET 的页面生命周期是硬编码的，框架只认Page这个基类。你写.aspx文件，服务器端编译时自动生成一个继承自Page的类，然后你的code-behind部分类再和它合并。如果你在code-behind里指定继承一个不继承Page的类，那等于告诉编译器“我要推翻整个页面模型”——它当然不干。

有人会问：那我用System.Web.UI.UserControl或者别的控件基类行不行？也不行。页面就是页面，控件就是控件，两者在对象模型里是平行的分支。你让页面继承用户控件基类，那跟让汽车继承飞机的翅膀一样，逻辑上就拧巴。

解决方案其实不复杂。要么让你的基类老老实实继承System.Web.UI.Page，要么就别用继承，改用组合——比如写个静态类做权限检查，在Page_Load里调用。或者用HttpModule拦截请求，那才是全局处理的正道。但很多人一上来就想着“我建个基类一了百了”，结果被这个报错卡住半天。

这个报错还有个变种，发生在.aspx文件的@Page指令里。你写Inherits="MyNamespace.MyBasePage"，但那个类没正确继承Page，同样报这个。而且有时候你引用的类在别的程序集里，类名写错了，也会报类似错误——但那个会提示“找不到类型”，跟这个“不扩展”是两码事。

我记得有个老项目，里面所有页面都继承一个叫BasePage的类，那个类本身继承Page，但后来有人重构，把BasePage的父类改成了Object——大概是觉得里面有些通用方法不需要页面生命周期。结果全站页面全炸，几十个文件同时报这个错。修的时候只能一个个改回去，或者全局替换继承关系。那场面，跟多米诺骨牌似的。

所以你看，这个报错的核心就一句话：ASP.NET 页面必须直接或间接继承System.Web.UI.Page。你绕不开，也别想绕。真要搞通用逻辑，先想清楚是页面级还是请求级。页面级的，继承Page没问题；请求级的，用IHttpModule。别把两件事混在一个类里。

最后说个冷知识：如果你真有个类不继承Page但想让它干活，你可以用HttpContext.Current.Handler拿到当前页面实例，然后通过接口调用方法。但那是歪门邪道，代码可读性差到爆，维护的人会想砍你。老老实实按规矩来，比啥都强。