简介基于ASP.NET MVC4与EasyUI的企业门户网站源码面向需要快速搭建公司官网或学习MVC分层开发的.NET开发者。系统整合新闻、产品、留言、下载、焦点图片等常用模块前台包含关于我们、产品中心、新闻中心、技术支持、人才招聘等栏目后台提供系统管理、新闻管理、产品管理、焦点图片管理、下载管理、链接管理等功能通用性强可直接用于多数企业门户场景。资源共2000个文件压缩包约37.03MB主要包含SVN版本控制文件、PNG/GIF/JPG图片、CSS样式、JavaScript脚本及DLL程序集另有.cshtml视图、.cs控制器和SQL数据库文件便于理解MVC4项目结构并做二次开发。已有712人学习下载DB_sql文件夹内数据库附加即可运行后台地址、默认账号密码及webconfig连接字符串修改方式均有注明适合企业网站建设者、.NET学习者参考与改造。1. 把「通用门户」做成骨架工程ASP.NET MVC4 的取舍与边界在 .NET 技术栈里「通用企业门户」是个看起来简单、做起来容易失控的方向。很多团队拿到的第一版需求都是登录、菜单、栏目、新闻发布、产品展示撑死加一个后台管理。但真正投入开发后就会发现门户网站最不值钱的是页面皮肤最值钱的是「内容-权限-布局」三者之间的数据结构关系。ASP.NET MVC4 之所以在这么多年后仍被不少存量系统沿用是因为它的路由、过滤器、Razor 布局页正好能把这层关系表达清楚又不像后来的 Core 版本那样频繁折腾配置体系。本文要解决的问题是一套可复用的通用门户源码其分层结构该怎么做数据表怎么设计权限过滤器怎么写以及部署到 IIS 后最常见的几个运行期坑。方向适合两类人——接手 MVC4 存量门户做二开的开发者以及想用老框架快速搭内部信息系统的团队。我把这套方案拆成「架构选型、骨架搭建、内容模型、部署排查、性能进阶」五个模块每个模块都落到可抄的代码和参数不扯空概念。文中提到的工程结构、表结构和代码片段都是我做同类门户时反复用过的套路照着搭能少走不少弯路。2. 架构与选型MVC4 门户的骨相决定后路门户类系统有个特点业务动作不多但页面形态特别多。同一个新闻首页要展示缩略图、栏目页要展示列表、详情页要展示正文、后台要展示编辑表单。如果架构上不分层最后会变成每个页面各写各的查询改一次需求牵连七八个文件。所以在动手写「通用门户」之前先把路由、数据访问、视图这三个层面的选型定下来。这三件事决定了后面所有功能的改造成本也是老手和新手拉开差距的地方。2.1 路由与 Area 分区多业务线门户的入口规划先说出问题的场景。一套通用企业门户通常至少包含前台展示和后台管理两个面。如果把所有控制器都堆在根 Controllers 目录下前期确实快但等到栏目类型超过 10 个、后台功能超过 20 个页面的时候光找文件就要花不少时间而且控制器同名冲突早晚会出现。管理后台和前台共享同一个 HomeController 是最常见的翻车现场前台改版时不小心动了后台的路由整站导航全乱。MVC4 的 Area 机制就是为这种多面场景准备的。我的习惯是前台保持默认路由后台统一放一个 Admin Area如果业务线还要横向扩展比如客户中心、招商平台再按业务线继续加 Area。路由注册的先后顺序很关键看代码// App_Start/RouteConfig.cs public class RouteConfig { public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute({resource}.axd/{*pathInfo}); // 默认路由锁死命名空间避免与 Area 里的控制器重名冲突 routes.MapRoute( name: PortalDefault, url: {controller}/{action}/{id}, defaults: new { controller Home, action Index, id UrlParameter.Optional }, namespaces: new[] { Demo.Portal.Web.Controllers } ); } }// Areas/Admin/AdminAreaRegistration.cs public class AdminAreaRegistration : AreaRegistration { public override string AreaName { get { return Admin; } } public override void RegisterArea(AreaRegistrationContext context) { // 后台统一带 /Admin 前缀和前台完全隔离 context.MapRoute( Admin_default, Admin/{controller}/{action}/{id}, new { controller Dashboard, action Index, id UrlParameter.Optional }, new[] { Demo.Portal.Web.Areas.Admin.Controllers } ); } }这段代码里有三个细节决定成败。第一namespaces 参数当前台和 Admin 都有自己的 DashboardController 时如果不锁命名空间MVC 解析 /Admin/Dashboard 可能抛出「找到了多个 Controller 类型」的异常这是 Area 最常见的坑。第二Admin 前缀/Admin/Content/List 这样的 URL 结构清晰做权限拦截时也方便——后面要讲的过滤器可以直接按 Area 判断。第三注册顺序在 Global.asax 的 Application_Start 里必须先 AreaRegistration.RegisterAllAreas()再执行 RouteConfig.RegisterRoutes否则默认路由会抢先吃掉 /Admin/xxx。提示调试路由时不要靠猜。我一般会在 Application_Start 里临时加一条日志把当前请求匹配到的 controller、action、area 打出来比对着配置文件肉眼排查快得多。2.2 数据访问层EF5 与原生 ADO.NET 的选型逻辑通用门户的数据访问场景可以粗分两类。一类是内容列表、详情、权限校验这类「表关系简单、访问频率高」的请求适合用 ORM 快速开发另一类是后台统计、跨栏目聚合、按自定义条件导出这类「SQL 复杂、返回结构多变」的请求用 ORM 反而要写一堆表达式树不如直接上原生 SQL。我的做法是 EF5 为主、原生 ADO.NET 为辅两个入口都在数据层内部封装业务层看不到区别。先看 EF5 的 DbContext 怎么搭。当时最稳的组合是 EF5 .NET Framework 4.5连接字符串和上下文类如下connectionStrings add namePortalConnection connectionStringData Source.;Initial CatalogDemoPortal;User Idportal_user;Password******;MultipleActiveResultSetsTrue; providerNameSystem.Data.SqlClient / /connectionStrings// Data/PortalContext.cs public class PortalContext : DbContext { public PortalContext() : base(namePortalConnection) { } public DbSetUserAccount Users { get; set; } public DbSetRole Roles { get; set; } public DbSetMenu Menus { get; set; } public DbSetCategory Categories { get; set; } public DbSetContent Contents { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { // 关闭内容表对栏目表的级联删除删栏目时内容必须保留避免误删整批数据 modelBuilder.EntityContent() .HasRequired(c c.Category) .WithMany() .WillCascadeOnDelete(false); } }连接字符串里值得注意的只有一项MultipleActiveResultSetsTrue。门户页面经常要在一个请求里同时跑多个查询比如取栏目列表的同时取最新一条新闻不开这个参数EF 在延迟加载时容易抛「连接已在使用中」的异常。Password 部分建议用 IIS 应用程序池的账户或加密配置节别把明文密码写在 web.config 里提交到仓库——这是血泪经验某公司就因此把数据库密码带进了内网代码库。至于原生 ADO.NET 的兜底场景我一般这样用// Data/DapperLikeExecutor.cs —— 不用 ORM 的最低成本方式 public DataTable ExecuteSql(string sql, params SqlParameter[] parameters) { using (var conn new SqlConnection(_connectionString)) { conn.Open(); using (var cmd new SqlCommand(sql, conn)) { cmd.CommandTimeout 30; cmd.Parameters.AddRange(parameters); var adapter new SqlDataAdapter(cmd); var table new DataTable(); adapter.Fill(table); return table; } } }这段代码适合后台报表、统计大屏这类「返回列不固定」的 SQL。注意 CommandTimeout 要显式设置门户后台导出数据时遇到大表默认 15 秒超时会让操作员以为网站卡死了。2.3 视图引擎Razor 布局页与分部视图的主题化拆分Razor 是 MVC4 时代最好用的视图引擎没有之一。通用门户的页面特点是有大量重复骨架——每个页面都是页头、导航、主体、页脚四层结构。如果每个视图都复制这套骨架改一次导航栏就是全站返工。正确姿势是用布局页和分部视图把骨架拆开。!-- Views/Shared/_Layout.cshtml -- !DOCTYPE html html head meta charsetutf-8 / titleViewBag.Title - SiteConfig.Current.SiteName/title RenderSection(Head, required: false) /head body header Html.Action(RenderTopNav, Menu) /header main RenderBody() /main footer Html.Partial(_Footer) /footer RenderSection(Scripts, required: false) /body /html布局页里最值得学的是 Html.Action(RenderTopNav, Menu) 这种子动作写法。导航菜单在每个页面都要渲染而且菜单数据来自数据库不是静态 HTML——如果放在布局页里直接用 Html.Partial那么每个页面都要在 Controller 里重复查一次菜单表。用子动作菜单的查询逻辑集中在 MenuController 里布局页只负责调用还能给这个子动作单独加缓存改动最小。另一个必须配的是 _ViewStart.cshtml它让所有视图默认继承同一个布局{ Layout ~/Views/Shared/_Layout.cshtml; }这样新建视图时不用手动指定布局。主题化改造也是从这里入手如果要做多套皮肤只需要让 Layout 路径从一个「当前主题名」变量拼接出来再配合 CSS 变量就能实现后台切换整站风格。这个做法在 MVC4 里 30 分钟就能跑通别引入复杂的主题引擎。3. 落地第一步把 MVC4 门户骨架跑通架构选型定下来之后就要动手搭工程骨架。这一步的目标不是写出多少页面而是把工程分层、数据库、登录授权这三个地基打牢。地基没打好后面加功能就像在沙地上盖楼——今天加一个栏目要改五个项目明天调一个权限要动三个表。下面的内容按我实际搭建的顺序来每一步都能直接复用。3.1 解决方案分层四个类库项目的引用方向我搭 MVC4 门户的习惯是五个项目Web 表现层、Service 业务层、Data 数据层、Model 实体层、Core 公共层。引用方向是单向的——Web 引用 ServiceService 引用 DataData 引用 ModelCore 被所有人引用。谁都不许反向引用这条规则用纪律保证否则项目会变成一团乱麻。Model 里只放 POCO 实体不加任何数据库访问逻辑。Data 层放 DbContext 和仓储接口Service 层放业务规则。控制器不允许直接碰 DbContext这是底线。下面是一个典型的仓储接口// Data/IContentRepository.cs public interface IContentRepository { Content GetById(int id); IListContent GetPaged(int categoryId, int pageIndex, int pageSize, out int total); void Insert(Content content); void Update(Content content); void Delete(int id); }Service 层把查询包装成更适合页面使用的形态// Service/ContentService.cs public class ContentService { private readonly IContentRepository _repo; public ContentService(IContentRepository repo) { _repo repo; } public IListContent GetPaged(int categoryId, int pageIndex, int pageSize, out int total) { // 分页参数必须做上限保护防止有人把 pageSize 改成 10000 拖垮数据库 pageSize Math.Min(pageSize, 100); return _repo.GetPaged(categoryId, Math.Max(pageIndex, 1), pageSize, out total); } }分页参数保护是我在项目里被真实流量教育过才加上的。门户网站总有写爬虫的访客拿着带 pageSize 的 URL 疯狂刷接口不做上限控制一个列表页就能把数据库连接池占满。至于控制器和 Service 的绑定MVC4 时代常见做法是构造器注入加一个轻量级 IoC 容器在 Global.asax 里统一注册生命周期——DbContext 按请求注册Service 按实例注册避免内存泄漏。3.2 核心表结构用户、角色、菜单、内容栏目的六张表通用门户的数据库设计核心就是六张表用户、角色、用户角色关联、菜单、栏目、内容。业务再怎么千变万化万变不离其宗。以下是精简后的建表脚本生产环境可以再加审计字段CreatedAt、UpdatedAt但不要在一开始就堆字段-- 用户表 CREATE TABLE dbo.UserAccount ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(50) NOT NULL, PasswordHash NVARCHAR(128) NOT NULL, -- 存哈希绝不存明文 FullName NVARCHAR(50) NULL, IsEnabled BIT NOT NULL DEFAULT 1, LastLoginAt DATETIME NULL ); -- 角色表 CREATE TABLE dbo.Role ( RoleId INT IDENTITY(1,1) PRIMARY KEY, RoleName NVARCHAR(50) NOT NULL, -- 显示名称比如「内容编辑」 RoleKey NVARCHAR(50) NOT NULL UNIQUE -- 判断用的键比如 editor ); -- 用户角色关联表 CREATE TABLE dbo.UserRole ( UserId INT NOT NULL REFERENCES dbo.UserAccount(UserId), RoleId INT NOT NULL REFERENCES dbo.Role(RoleId), PRIMARY KEY (UserId, RoleId) ); -- 菜单表自引用树支持无限级 CREATE TABLE dbo.Menu ( MenuId INT IDENTITY(1,1) PRIMARY KEY, ParentId INT NULL REFERENCES dbo.Menu(MenuId), MenuName NVARCHAR(50) NOT NULL, Url NVARCHAR(200) NULL, -- NULL 表示目录节点 SortOrder INT NOT NULL DEFAULT 0, Target NVARCHAR(20) NULL -- _blank / _self ); -- 栏目表同样自引用区分栏目类型 CREATE TABLE dbo.Category ( CategoryId INT IDENTITY(1,1) PRIMARY KEY, ParentId INT NULL, CategoryName NVARCHAR(100) NOT NULL, CategoryType TINYINT NOT NULL DEFAULT 1, -- 1新闻 2产品 3下载 4单页 SortOrder INT NOT NULL DEFAULT 0, IsShow BIT NOT NULL DEFAULT 1 ); -- 内容表 CREATE TABLE dbo.Content ( ContentId INT IDENTITY(1,1) PRIMARY KEY, CategoryId INT NOT NULL REFERENCES dbo.Category(CategoryId), Title NVARCHAR(200) NOT NULL, Summary NVARCHAR(500) NULL, Body NTEXT NULL, CoverImageUrl NVARCHAR(300) NULL, PublisherId INT NOT NULL, PublishTime DATETIME NOT NULL DEFAULT GETDATE(), ViewCount INT NOT NULL DEFAULT 0, IsTop BIT NOT NULL DEFAULT 0, -- 置顶 IsEnabled BIT NOT NULL DEFAULT 1 ); -- 最关键的一个索引栏目 发布时间门户列表查询全靠它 CREATE INDEX IX_Content_Category_Publish ON dbo.Content(CategoryId, PublishTime DESC);六张表里最容易被忽视的是 CategoryType 字段。它决定了这个栏目下的内容长什么样——新闻要显示发布时间和摘要产品要显示图片和规格下载要显示附件大小单页只有正文。不在表里做这个区分后台就会被迫做一堆 if else 判断。另外ParentId 虽然允许无限级但业务上深度超过 3 级几乎没人用我一般会在 Service 层限制最大层级防止递归查询失控。3.3 登录与授权FormsAuth 票据与自定义 AuthorizeAttribute门户的登录认证MVC4 时代最成熟的是 FormsAuthentication配合自定义的 AuthorizeAttribute 做角色判断。不要用 Session 存用户信息——Session 过期、应用池回收、负载均衡都会让登录状态莫名其妙丢失属于典型的黑匣子问题。FormsAuth 的票据存在加密 Cookie 里天然跨请求、跨服务器只要 MachineKey 一致。// Web/Controllers/AccountController.cs [HttpPost] [AllowAnonymous] [ValidateAntiForgeryToken] public ActionResult Login(LoginViewModel model, string returnUrl) { if (!ModelState.IsValid) return View(model); // 1. 校验用户名与密码哈希 var user _userService.ValidateLogin(model.UserName, model.Password); if (user null) { ModelState.AddModelError(, 用户名或密码错误); return View(model); } // 2. 把角色键拼进票据 UserData避免每个请求都查数据库 var ticket new FormsAuthenticationTicket( 1, // 版本号 user.UserName, // 用户名 DateTime.Now, // 签发时间 DateTime.Now.AddHours(8), // 过期时间后台系统 8 小时合理 model.RememberMe, // 持久化 Cookie string.Join(,, user.RoleKeys), // UserData角色列表 FormsAuthentication.FormsCookiePath ); var encrypted FormsAuthentication.Encrypt(ticket); var cookie new HttpCookie(FormsAuthentication.FormsCookieName, encrypted) { HttpOnly true, // 禁止脚本读取防 XSS 偷 Cookie SameSite SameSiteMode.Lax }; Response.Cookies.Add(cookie); // 3. 跳回用户原本想访问的页面 return Redirect(string.IsNullOrEmpty(returnUrl) ? Url.Action(Index, Home) : returnUrl); }把角色塞进 UserData 是个关键取舍。很多初版代码在 AuthorizeAttribute 里判断权限时每次都回数据库查用户角色。门户网站的导航、内容发布、后台菜单都要做权限判断一次请求可能触发五六次角色查询数据库压力就上来了。塞进票据后每次请求从解密后的 UserData 里拆字符串就行零数据库开销。代价是角色变更要等票据过期才生效所以后台要提供一个「强制重新登录」的按钮管理员调整角色后让用户重登一次。自定义过滤器要处理的坑比想象中多尤其是「未登录」和「已登录但无权限」必须区分开// Web/Infrastructure/PortalAuthorizeAttribute.cs public class PortalAuthorizeAttribute : AuthorizeAttribute { protected override bool AuthorizeCore(HttpContextBase httpContext) { var identity httpContext.User.Identity; if (!identity.IsAuthenticated) return false; // 从 FormsAuthenticationTicket.UserData 里取角色 var ticket ((FormsIdentity)identity).Ticket; var roleKeys ticket.UserData.Split(,); var required Roles.Split(,); return required.Any(r roleKeys.Contains(r)); } protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext) { if (!filterContext.HttpContext.User.Identity.IsAuthenticated) { // 未登录跳登录页带上回跳地址 filterContext.Result new RedirectToRouteResult( new RouteValueDictionary { { controller, Account }, { action, Login }, { returnUrl, filterContext.HttpContext.Request.RawUrl } }); } else { // 已登录但没权限显示 403 页面不要跳登录页 filterContext.Result new ViewResult { ViewName Forbidden }; } } }这段代码的边界在于已登录用户访问无权限页面时如果也跳到登录页而登录页本身是 AllowAnonymous 的用户绕一圈就陷入了「登录 → 跳转 → 再登录」的死循环。门户后台的用户角色复杂后这个问题一定会出现不如一开始就分干净。4. 内容管理落地栏目树与模板块的通用化骨架跑通后开始填血肉。通用门户的难点不在单个页面而在「内容模型能否撑住不同类型的栏目」。新闻、产品、下载、单页这四类栏目形态差异很大但后台管理逻辑高度相似——都要列表、新增、编辑、删除、置顶。这一章解决两个问题栏目树怎么存首页模板块怎么做到可配置。4.1 栏目树自引用表与内存拼树避免递归查库栏目表用 ParentId 自引用数据层面很简单难的是读取和渲染。最容易犯的错是「递归查库」——从根栏目开始每下一层查一次数据库。四级栏目就是四次往返页面加载时间随栏目深度线性恶化。正确做法是一次性取出全表在内存里拼树// Service/CategoryService.cs public ListCategory GetTree() { // 一次取全部栏目在内存里递归拼树杜绝 N1 查询 var all _categoryRepository.GetAll(); // 只查一次 return BuildTree(all, null); } private ListCategory BuildTree(ListCategory all, int? parentId) { return all.Where(c c.ParentId parentId) .Select(c { c.Children BuildTree(all, c.CategoryId); return c; }) .OrderBy(c c.SortOrder) .ToList(); }BuildTree 在内存里递归传入的是全量数据递归过程只做 LINQ 过滤零数据库访问。表里几十上百条栏目数据这种方式毫秒级完成。注意父级为空ParentId IS NULL的栏目要写成 parentId 参数传 null对应 C# 的可空 int别漏了。另外建议加一个深度上限保护当递归层级超过 5 时抛异常防止有人手动改库把栏目表搞成环——自引用表一旦成环这个递归就永远跑不完直接把网站打挂。4.2 首页模板块用子动作渲染可配置区域门户首页的信息架构通常是一堆区块——头条新闻、产品推荐、最新下载、公告栏。每个区块有自己的数据来源和显示样式。最僵硬的写法是把这些区块全部写死在首页视图里改一个区块就要动首页代码。通用做法是把「区块」抽象成配置项每个区块对应一个子动作和分部视图// Web/Models/HomeBlockConfig.cs public class HomeBlockConfig { public string BlockKey { get; set; } // 例如 news_top、product_hot public string PartialViewName { get; set; } // 例如 Blocks/_NewsTop public int CategoryId { get; set; } // 数据来源栏目 public int Count { get; set; } // 取几条 public int SortOrder { get; set; } // 区块上下顺序 }首页视图只负责按配置顺序渲染区块model ListHomeBlockConfig foreach (var block in Model.OrderBy(b b.SortOrder)) { Html.Action(RenderBlock, HomeBlock, new { blockKey block.BlockKey, categoryId block.CategoryId, count block.Count }) }HomeBlockController 里的 RenderBlock 动作要单独处理数据查询和缓存// Web/Controllers/HomeBlockController.cs [OutputCache(Duration 60, VaryByParam blockKey;categoryId;count)] public ActionResult RenderBlock(string blockKey, int categoryId, int count) { // blockKey 必须做白名单校验防止被拼成任意视图路径 var allowed new[] { news_top, product_hot, download_latest }; if (!allowed.Contains(blockKey)) return Content(); count Math.Min(Math.Max(count, 1), 20); var list _contentService.GetList(categoryId, count, isTopFirst: true); return PartialView(Blocks/ blockKey, list); }这个设计的价值在于后台管理人员通过配置表的增删改就能调整首页区块不用动代码。count 参数做了上下限保护防止有人调接口时把 count 传成 1000 拉全表。OutputCache 的 Duration 设 60 秒前台内容是门户展示型信息秒级延迟可以接受但数据库压力能降一个量级。4.3 后台列表与保存一套路由约定吃遍内容类型后台管理的套路化程度比前台高得多。我的做法是约定优于配置所有内容类型的列表页都走同一个路由结构 /Admin/{ContentType}/List新增走 /Admin/{ContentType}/Create编辑走 /Admin/{ContentType}/Edit/{id}。每个内容类型对应一个继承自统一基类的控制器基类把查询、分页、保存的通用逻辑都做了// Areas/Admin/Controllers/ContentBaseController.cs public abstract class ContentBaseController : Controller { protected abstract int CategoryType { get; } [PortalAuthorize(Roles admin,editor)] public ActionResult List(int categoryId, int page 1) { int total; var list _contentService.GetPaged( categoryId, page, pageSize: 15, out total); ViewBag.TotalCount total; ViewBag.CurrentPage page; ViewBag.CategoryId categoryId; return View(List, list); } [HttpPost] [PortalAuthorize(Roles admin,editor)] [ValidateInput(false)] // 富文本场景需要见第 5 章避坑 [ValidateAntiForgeryToken] public ActionResult Save(ContentViewModel model) { if (!ModelState.IsValid) { // 校验失败返回编辑页ViewBag 里保留错误提示 return View(Edit, model); } // 清洗富文本中的危险标签必须做 model.Body HtmlSanitizer.Sanitize(model.Body); _contentService.Save(model); return RedirectToAction(List, new { categoryId model.CategoryId }); } }子类只需要声明 CategoryType 并补充自己特有的校验逻辑。新闻、产品、下载四个控制器各二三十行代码就齐了。这套约定的优点是新人上手快看一个类型的实现就知道其他类型怎么改。缺点是灵活性受限——如果某类内容有独特的字段和交互需要覆写基类方法所以基类里的方法都要标 virtual别把路堵死。5. MVC4 门户开发与部署避坑指南这一章是全文最值钱的部分。下面四个问题几乎每个 MVC4 门户项目都会踩到我把现象、原因、解决写在一起每一条都是实际环境里花了不少时间才定位出来的。有些问题表面上像玄学实际追到根上都是配置或生命周期的疏忽。5.1 现象一后台保存了内容前台首页还是旧数据后台明明提示「保存成功」刷新前台首页新内容就是不出来。隔一段时间又自己出来了。原因基本是 OutputCache 在作怪。门户首页为了性能会在 Action 上加 OutputCache缓存了整页或某个区块后台保存操作不会通知缓存失效。我之前排查时盯着代码看了两个小时怎么都想不通逻辑哪里有 bug最后发现是首页 [OutputCache(Duration 60)] 把整个页面缓存了——保存后 60 秒内刷新当然看不到新内容。解决不要依赖缓存自动过期在保存内容的 Service 方法里主动清缓存。OutputCache 的清缓存接口是 HttpResponse.RemoveOutputCacheItem但更可控的做法是把缓存粒度缩小到区块级别像 4.2 节那样再在后台保存时调一次// Service/ContentService.cs public void Save(Content model) { _repo.Save(model); // 让首页区块缓存随站点版本号失效见第 6 章 SiteConfig.Current.Version; }5.2 现象二发布到 IIS 后无扩展名 URL 全部 404本地开发用 IIS Express 一切正常部署到生产 IIS 后首页能打开但 /Home/About、/Admin/Content/List 这类无扩展名 URL 全部 404。静态文件图片、CSS正常。原因应用程序池用了经典模式Classic .NET AppPool经典模式下 IIS 只把带扩展名的请求交给 ASP.NET 处理无扩展名请求直接走静态文件处理器MVC 路由根本收不到。解决把应用程序池改成集成模式Integrated这是最干净的做法。如果因为历史原因必须用经典模式就要给无扩展名请求加通配符映射在 IIS 的「处理程序映射」里添加一个路径为*、类型为System.Web.Handlers.TransferRequestHandler的通配符脚本映射。集成模式下还要检查 web.config 里有没有 ExtensionlessUrlHandler 的注册IIS 7.5 及以上版本在安装 ASP.NET 4.5 时会自动注册如果被手动删掉同样会出现默认页面能开、路由页面全 404 的诡异现象。注意部署前用浏览器直接访问一个带扩展名的地址比如 /Home/Index.cshtml并不会暴露路由问题因为 .cshtml 后缀意味着不走路由。真正有效的验证方式是访问一个纯路由的 URL比如 /Home/About404 还是 200 一目了然。5.3 现象三登录成功后反复弹回登录页登录成功地址栏跳回目标页面马上又被重定向到登录页再登录再弹回陷入死循环。这个问题的常见原因有两种现象一样但根因不同。第一代码里用了 Session 存登录状态登录时把用户对象塞进 SessionAuthorizeAttribute 校验时发现 Session 是空的判定未登录。而应用池默认 20 分钟回收一次回收后 Session 全丢用户就被「打回原形」。Session 丢是 InProc 模式的老毛病尤其在内存压力大的服务器上很频繁。第二部署了多台服务器做负载均衡FormsAuth 的加密票据解不开A 服务器加密的 Cookie 到了 B 服务器B 的 machineKey 和 A 不一致解密失败Identity.IsAuthenticated 返回 false。解决方式把 machineKey 显式配置到 web.config而不是让每台服务器自己生成system.web machineKey validationKey这里填64位十六进制密钥 decryptionKey这里填32位十六进制密钥 validationSHA1 decryptionAES / /system.webmachineKey 是负载均衡场景的后悔药。没有它FormsAuth、防伪令牌、ViewState 在多服务器环境下都会出现「间歇性失灵」——今天能在 A 服务器登录明天负载均衡把请求转发到 B 服务器就退出登录。记住多服务器部署machineKey 必须手工指定且保持一致用生成工具离线生成密钥写死在配置里。5.4 现象四富文本保存直接被截断或页面布局错乱后台编辑器里贴了一段带格式的 HTML比如从 Word 复制的内容保存时报「检测到有潜在危险的 Request.Form 值」这是 ASP.NET 4.5 的请求验证机制在拦截。很多人的第一反应是全站关闭验证或给 Save 方法加 [ValidateInput(false)]这样能保存了但接下来还有两个连环坑。第一个坑是 XSS保存进来的 HTML 里带script、onerror事件前台渲染用 Html.Raw 输出脚本直接在访客浏览器里执行。第二个坑是样式污染从 Word 复制的 HTML 带大量 inline style 和冗余嵌套标签渲染出来页面布局错乱。解决只在富文本保存这一个 Action 上开 [ValidateInput(false)]绝不全局关闭保存前用白名单方式清洗 HTML只保留 p、a、img、strong、em、ul、ol、li 这些安全标签去掉 script、iframe、object、style 以及所有 on* 事件属性// Infra/HtmlSanitizer.cs public static string Sanitize(string html) { if (string.IsNullOrWhiteSpace(html)) return html; // 先剥掉危险标签再剥事件属性 var disallowedTags new[] { script, iframe, object, embed, style }; foreach (var tag in disallowedTags) html Regex.Replace(html, $\s*{tag}[^]*.*?\s*/\s*{tag}, , RegexOptions.IgnoreCase); html Regex.Replace(html, \son\w\s*\s*[^]*, , RegexOptions.IgnoreCase); return html; }这套处理在后台是必须过的关卡哪怕你们团队只有三个人用后台。门户网站一旦被注入脚本影响的是所有访问者而且脚本往往藏在历史文章里清理成本极高。把 Sanitize 放在 Save 方法的入口当成发布流程的强制环节不要指望每个编辑人员都自觉不贴危险代码。6. 再进一步缓存分级与接口化改造的最小路径门户跑起来之后下一步通常只有两个方向性能还不够要再压一压或者业务方要求出 App 和第三方系统对接要走接口。这两个方向在 MVC4 里都有低成本的最小改造路径不需要把系统推倒重来。6.1 OutputCache 与 VaryByCustom让缓存跟随站点配置失效区块级 OutputCache 已经能挡掉大部分重复查询但还有一个细节后台改了站点标题或主题皮肤前台缓存却不失效。解决办法是用 VaryByCustom把缓存跟「站点配置版本号」绑定// Global.asax.cs public override string GetVaryByCustomString(HttpContext context, string custom) { if (custom SiteVersion) return SiteConfig.Current.Version.ToString(); return base.GetVaryByCustomString(context, custom); }Action 上的 OutputCache 增加 VaryByCustom 参数[OutputCache(Duration 60, VaryByParam blockKey;categoryId;count, VaryByCustom SiteVersion)] public ActionResult RenderBlock(string blockKey, int categoryId, int count)这样后台每保存一次配置或内容SiteConfig.Current.Version 自增所有区块缓存瞬间失效下一个请求重新生成缓存。这个技巧比手动 RemoveOutputCacheItem 更省心不用记一堆缓存键。顺带一提输出缓存建议从首页整页缓存改成区块缓存——整页缓存会把用户登录状态的显示也缓存进去导致页面右上角一直显示别人的用户名这类问题在门户项目里出现过不止一次。6.2 在 MVC4 工程里加 Web API接口化改造的最小路径移动端要数据、合作伙伴要对接最直接的方案是在同一套工程里加 Web API而不是单独起一个 Web API 项目——单独起项目意味着要处理跨域、会话、权限的重复实现是给自己挖坑。MVC4 本身支持在同项目里注册 Web API 路由加一个 ApiController 就能输出 JSON// Web/Controllers/Api/ContentApiController.cs public class ContentApiController : ApiController { [HttpGet] public IHttpActionResult List(int categoryId, int page 1, int pageSize 10) { // 接口场景的 pageSize 上限要比页面更严 pageSize Math.Min(Math.Max(pageSize, 1), 20); int total; var list _contentService.GetPaged(categoryId, page, pageSize, out total); return Ok(new { code 0, data list.Select(c new { c.ContentId, c.Title, c.Summary, c.PublishTime, c.IsTop }), total total }); } }路由注册在 App_Start/WebApiConfig.cspublic static class WebApiConfig { public static void Register(HttpConfiguration config) { // /api/ContentApi/List?categoryId1page1pageSize10 config.Route(routes { routes.MapHttpRoute( name: DefaultApi, routeTemplate: api/{controller}/{action}/{id}, defaults: new { id RouteParameter.Optional } ); }); } }这里用{action}风格的路由是因为门户接口基本都是一对对的具体操作List、Detail、Submit比纯 RESTful 风格更直白少写很多路由特性。ApiController 和 MVC 的 FormsAuth 是同一个管道Cookie 里带着票据就能访问接口省去了给 App 单独做 Token 的逻辑。等流量大了再在这个基础上加签名验证也不迟——第一步永远是先让数据能通过接口稳定地出去和进来别一上来就设计一整套权限网关。我的习惯是门户上线后先盯一周的缓存命中率和慢查询日志再决定要不要继续压性能接口化改造则一定放在业务方明确提出对接需求之后不做预埋式设计。这套 MVC4 的骨架我用过好几轮每次接手旧项目时都把缓存失效、machineKey、富文本清洗这三件事列为第一优先级检查项避免它们在项目里埋雷。希望这一篇能帮你在搭或者改门户系统时少走些弯路。本文还有配套的精品资源点击获取