简介面向.NET开发者与企业信息化建设人员的企业门户网站完整源码包围绕新闻发布、用户管理、权限控制与个性化展示等常见门户需求提供一套可运行、可拆解的ASP.NET Web Forms项目参考适合课程设计、毕业设计及中小型企业门户二次开发场景。压缩包共211个文件以38个C#源码、21个ASPX页面、4个ASCX用户控件和2个ASHX处理程序为核心辅以DLL程序集、CSS/JS静态资源、GIF/JPG界面素材、配置文件及MDF/LDF数据库文件整体约2.08MB目录覆盖前台展示与后台管理两条主线。目前已有375人学习下载说明其在.NET入门与门户项目实践中具有一定参考价值。项目包含新闻发布、用户登录与用户管理、权限验证、母版页布局、数据库连接配置及IIS部署说明等模块读者可据此梳理ASP.NET Web Forms的页面组织方式、控件复用思路与后台数据操作流程也能对照配置文件快速理解运行环境要求为二次开发与部署排错提供依据。1. 需求先行企业门户网站真正难的不是首页好不好看编辑部要换首页轮播图得排队等开发排期栏目从五个加到二十个后台下拉框开始卡手机打开首页图片横着溢出屏幕。做过 .NET 企业门户网站的人都清楚这类问题的根源通常不在页面写得好不好看而在于内容模型没立住、模块边界没划清。这套完整版方案要解决的就是三件事栏目和内容可配置、前台呈现与后台管理解耦、权限与发布流程可追溯。它适合正在做企业门户网毕设或课程设计的同学也适合要交付一套可维护门户系统的从业者——照着这套结构搭至少不会在“加一个栏目就要改三张表”这种地方反复踩坑。2. 总体架构设计四层结构与七个模块的职责边界门户网站的技术选型没什么玄学ASP.NET Core 配 EF Core、SQL Server前台用 Razor 渲染足够覆盖绝大多数企业门户的访问量。真正需要提前想清楚的是分层控制器里塞满业务逻辑后期每加一个功能都要动同一批文件这是很多课程设计做到一半就推不动的直接原因。我的做法是把解决方案拆成五个项目依赖方向严格单向表现层只认应用服务应用服务只认领域接口基础设施负责把接口落到 EF Core 和文件系统上。2.1 解决方案分层与项目目录目录结构不是摆样子它决定了你后面找代码的速度src/ ├── Portal.Web/ 表现层控制器、Razor 视图、静态资源、中间件 ├── Portal.Application/ 应用服务用例编排、DTO、参数校验 ├── Portal.Domain/ 领域模型实体、枚举、仓储接口 ├── Portal.Infrastructure/ 基础设施EF Core 上下文、仓储实现、缓存、文件存储 └── Portal.Tests/ 单元测试与集成测试项目核心职责允许依赖Portal.Web路由、模型绑定、视图渲染、过滤器ApplicationPortal.Application文章发布、栏目维护等用例编排DomainPortal.Domain实体定义、状态枚举、仓储契约无Portal.Infrastructure数据库访问、缓存读写、上传落盘DomainPortal.Tests针对应用服务的用例测试Application、Infrastructure这套分层的价值在“发布文章”这个用例上体现得最明显校验、状态流转、缓存失效、审计日志都收在应用服务里控制器只负责接参数和返回视图。后面要给文章加一个“定时发布”功能改动范围就锁定在一个类里。很多同学图省事把逻辑写在 Controller答辩时被问“业务逻辑在哪一层”就答不上来这不是概念问题是后面改需求时真要返工。2.2 模块注册与依赖注入配置七个业务模块分别是内容管理、栏目管理、用户与角色、权限点、媒体资源、前台渲染、系统设置。它们不需要各自独立部署但在代码里要有清晰的服务接口。启动配置集中在入口文件里读起来一目了然var builder WebApplication.CreateBuilder(args); builder.Services.AddControllersWithViews(); builder.Services.AddDbContextPortalDbContext(options options.UseSqlServer(builder.Configuration.GetConnectionString(Portal))); // 应用服务统一注册为 Scoped与一次请求的生命周期对齐 builder.Services.AddScopedICategoryService, CategoryService(); builder.Services.AddScopedIArticleService, ArticleService(); builder.Services.AddScopedIMediaService, MediaService(); builder.Services.AddScopedIPermissionChecker, PermissionChecker(); builder.Services.AddMemoryCache(); builder.Services.ConfigureUploadOptions(builder.Configuration.GetSection(Upload));生命周期别乱选DbContext 和业务服务都用 Scoped跟着请求走缓存由框架托管为单例不要自己 new。UploadOptions对应配置文件里的节点通常包含MaxSizeMB、AllowExtensions、RootPath三个键改上传限制不用重新编译。我一般还会加一个AddScopedICurrentUser, CurrentUser把当前登录人、角色、数据范围统一从 HttpContext 里取出来后面做权限判断和审计日志都靠它。2.3 核心数据表与索引设计门户的数据模型不复杂但字段设计要考虑三件事栏目能不能无限层级、文章要不要软删除、列表页查询走不走索引。栏目表用物化路径存层级文章表把发布状态和发布时间分开存CREATE TABLE Category ( Id INT IDENTITY(1,1) PRIMARY KEY, ParentId INT NULL, Name NVARCHAR(50) NOT NULL, Slug VARCHAR(80) NOT NULL, Path VARCHAR(400) NOT NULL, -- 形如 /1/5/12/便于前缀查询子孙栏目 SortOrder INT NOT NULL DEFAULT 0, IsEnabled BIT NOT NULL DEFAULT 1, CreatedAt DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME() ); CREATE UNIQUE INDEX UX_Category_Slug ON Category(Slug); CREATE INDEX IX_Category_Path ON Category(Path); CREATE TABLE Article ( Id INT IDENTITY(1,1) PRIMARY KEY, CategoryId INT NOT NULL, Title NVARCHAR(200) NOT NULL, Summary NVARCHAR(500) NULL, Content NVARCHAR(MAX) NULL, CoverUrl VARCHAR(300) NULL, Status TINYINT NOT NULL DEFAULT 0, -- 0草稿 1待审 2已发布 3已下线 IsTop BIT NOT NULL DEFAULT 0, PublishedAt DATETIME2 NULL, IsDeleted BIT NOT NULL DEFAULT 0, CreatedAt DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME() ); CREATE INDEX IX_Article_Category_Status ON Article(CategoryId, Status, PublishedAt DESC);Slug上加唯一索引是因为前台伪静态路由要靠它定位栏目重复了就会出现两个栏目抢同一个地址。文章表的联合索引按“栏目 状态 发布时间倒序”建正好覆盖列表页最常见的查询条件翻到第十页也不会全表扫描。软删除字段IsDeleted必须配全局查询过滤器否则某个查询忘了加条件回收站里的文章就会漏到前台。3. 内容管理后台栏目树、发布状态机与资源管理后台是整套门户网站使用频率最高的部分运营人员每天在里面建栏目、写文章、传图。这一层的设计目标很朴素栏目层级再深也不卡、文章从草稿到上线有据可查、上传的图片不会互相覆盖。下面四个小节对应四块最容易做糙的地方。3.1 栏目树建模物化路径替代递归查询无限层级栏目的常见写法是查全表再在内存里递归建树——数据量小的时候没感觉栏目上百以后每次打开后台都要把整表拉一遍。更稳妥的做法是给每个栏目维护Path字段新增时把父级路径拼上自己的 Id查子孙栏目就变成一次前缀匹配public async TaskListCategoryNode GetTreeAsync() { // 一次查询取回启用栏目按排序号排好内存中组装树结构 var list await _db.Categories .Where(c c.IsEnabled) .OrderBy(c c.SortOrder) .Select(c new CategoryNode { Id c.Id, ParentId c.ParentId, Name c.Name, Slug c.Slug, Path c.Path }) .ToListAsync(); var lookup list.ToLookup(c c.ParentId); foreach (var node in list) { node.Children lookup[node.Id].ToList(); } return lookup[null].ToList(); }一次查询加上ToLookup建索引复杂度是线性的层级再深也不会额外产生 SQL。新增栏目时由应用服务计算Path parent.Path id /父级为空则写/{id}/。删除栏目要先判断有没有子栏目和已发布文章有的话拒绝删除改为提示先迁移——这条规则写进服务层别指望前端按钮置灰能拦住。3.2 文章发布状态机与审核留痕文章状态用枚举固定成四态流转规则写在服务里不允许控制器直接改状态字段public enum ArticleStatus { Draft 0, PendingReview 1, Published 2, Offline 3 } public async TaskResult PublishAsync(int articleId, int operatorId) { var article await _db.Articles.FirstOrDefaultAsync(a a.Id articleId !a.IsDeleted); if (article is null) return Result.Fail(文章不存在); if (article.Status ! ArticleStatus.PendingReview) return Result.Fail(只有待审状态的文章可以发布); if (string.IsNullOrWhiteSpace(article.Title)) return Result.Fail(标题不能为空); if (!await _db.Categories.AnyAsync(c c.Id article.CategoryId c.IsEnabled)) return Result.Fail(所属栏目已停用); article.Status ArticleStatus.Published; article.PublishedAt DateTime.UtcNow; await _db.SaveChangesAsync(); await _audit.LogAsync(operatorId, article.publish, articleId); // 审核留痕 return Result.Ok(); }状态判断放在服务层而不是页面上是因为同一个接口可能被后台页面、批量操作、定时任务多处调用。审核留痕单独记一张AuditLog表字段包含操作人、动作、对象 Id、时间、IP答辩时被问“内容谁改的怎么查”这张表就是答案。发布成功后顺手触发一次前台缓存失效这一步在下一章展开。3.3 媒体上传白名单、重命名与目录分片上传功能出问题往往出在两个地方一是拿原始文件名直接落盘两个人传了同名的banner.jpg就互相覆盖二是只校验前端传来的扩展名改个后缀就能传可执行文件。靠谱的写法是服务端二次校验文件名统一重命名目录按年月分片private static readonly string[] AllowedExt { .jpg, .jpeg, .png, .gif, .webp, .pdf }; public async Taskstring SaveAsync(IFormFile file) { var ext Path.GetExtension(file.FileName).ToLowerInvariant(); if (!AllowedExt.Contains(ext)) throw new BizException(不支持的文件类型); if (file.Length _options.MaxSizeMB * 1024 * 1024) throw new BizException(文件超出大小限制); var relativeDir $uploads/{DateTime.Now:yyyy}/{DateTime.Now:MM}; var dir Path.Combine(_env.WebRootPath, relativeDir); Directory.CreateDirectory(dir); // 目录不存在时自动创建 var newName ${Guid.NewGuid():N}{ext}; var fullPath Path.Combine(dir, newName); await using var stream System.IO.File.Create(fullPath); await file.CopyToAsync(stream); return $/{relativeDir}/{newName}; }用 GUID 重命名彻底避免同名覆盖和中文文件名编码问题按年月分目录单目录文件数不会膨胀到影响文件系统遍历。返回的是相对路径数据库里只存这个相对地址将来换存储位置或者挂 CDN 只需要改一个配置项。3.4 权限点与动态菜单只按角色判断“是不是管理员”在门户里不够用因为会出现“编辑能发文章但不能删栏目”这种细分需求。做法是定义权限点角色和权限点多对多后台菜单按当前用户拥有的权限点动态过滤public async Taskbool HasPermissionAsync(int userId, string permissionCode) { // 用户 - 角色 - 权限点 三级关联结果缓存 5 分钟 var key $perm:{userId}; var codes await _cache.GetOrCreateAsync(key, async entry { entry.AbsoluteExpirationRelativeToNow TimeSpan.FromMinutes(5); return await _db.UserRoles .Where(ur ur.UserId userId) .Join(_db.RolePermissions, ur ur.RoleId, rp rp.RoleId, (ur, rp) rp.PermissionCode) .Distinct() .ToListAsync(); }); return codes.Contains(permissionCode); }权限点命名建议用“资源.动作”的格式例如article.create、article.publish、category.delete含义直白前端菜单只需要比对编码前缀。缓存时间不宜过长角色调整后要么等五分钟要么在角色保存时主动清掉该用户的键——后者更符合直觉。4. 前台门户渲染伪静态路由、响应式与 SEO前台是给访客看的衡量标准只有三条打开快、手机上不乱、搜索引擎能收录。Razor 服务端渲染在这三件事上比前后端分离更省事首屏内容直接随 HTML 返回不需要等 JavaScript 拉接口。下面按路由、性能、SEO、缓存四块说。4.1 伪静态路由与页面渲染栏目页和文章详情页的地址尽量做成.html结尾路由在入口处统一配置app.MapControllerRoute( name: article, pattern: news/{id:int}.html, defaults: new { controller Article, action Detail }); app.MapControllerRoute( name: category, pattern: {slug}/list_{page:int}.html, defaults: new { controller Category, action List, page 1 }); app.MapControllerRoute( name: default, pattern: {controllerHome}/{actionIndex}/{id?});注意路由顺序默认路由必须放最后否则会把news/123.html当成控制器名去匹配。栏目页的slug从数据库校验存在性不存在直接返回 404不要回落到首页——搜索引擎会把回落当成大量重复内容。详情页只查需要的字段正文内容在渲染时直接输出避免视图里再发起数据库调用。4.2 响应式布局与首屏性能移动端适配不靠单独做一套手机站用栅格加断点就够了。真正影响体验的是首屏资源图片全部加loadinglazy非首屏的轮播图不预加载CSS 和 JS 在发布时合并压缩静态资源引用带上版本号避免用户拿到旧缓存link relstylesheet href~/css/site.min.css asp-append-versiontrue / script src~/js/site.min.js asp-append-versiontrue defer/scriptasp-append-version会根据文件内容生成哈希后缀文件一改地址就变浏览器自然重新拉取。首页这种更新频率低的页面可以启响应压缩和短时输出缓存通常设置 60 秒就够既能挡住大部分重复请求又不至于让运营改完内容看不到效果。列表页的分页参数记得做上限校验page传个一万也要能正常返回空列表而不是拼出超长 SQL。4.3 SEO站点地图、结构化数据与栏目 TDK门户网站的流量很大一部分来自搜索三样东西必须齐全每页的标题、描述、关键词从栏目或文章字段取不要写死sitemap.xml动态生成包含所有已发布文章和启用栏目robots.txt指向站点地图地址。[HttpGet(/sitemap.xml)] public async TaskIActionResult Sitemap() { var articles await _db.Articles .Where(a a.Status ArticleStatus.Published !a.IsDeleted) .OrderByDescending(a a.PublishedAt) .Take(5000) .Select(a new { a.Id, a.PublishedAt }) .ToListAsync(); var sb new StringBuilder(); sb.AppendLine(?xml version\1.0\ encoding\utf-8\?); sb.AppendLine(urlset xmlns\http://www.sitemaps.org/schemas/sitemap/0.9\); foreach (var a in articles) { sb.AppendLine($urlloc{_site.BaseUrl}/news/{a.Id}.html/loc); sb.AppendLine($lastmod{a.PublishedAt:yyyy-MM-dd}/lastmod/url); } sb.AppendLine(/urlset); return Content(sb.ToString(), application/xml, Encoding.UTF8); }五千条是单文件站点地图的常见上限超过就拆成多个文件再用索引文件串起来。文章详情页还可以输出面包屑和 JSON-LD 结构化数据这两样对收录和展示都有实际帮助代码量不大别省。4.4 缓存键设计与发布失效前台读多写少缓存收益明显但键的命名必须有规律否则缓存更新很容易变成“改了内容前台还是旧的”这类问题public static class CacheKeys { public static string CategoryTree() portal:cat:tree; public static string ArticleList(int categoryId, int page) $portal:art:list:{categoryId}:{page}; public static string ArticleDetail(int id) $portal:art:detail:{id}; public static string SiteSettings() portal:settings; }发布文章后按前缀清理相关键栏目树、该栏目的前几页列表、文章详情缓存。清理动作放在应用服务的发布方法末尾和状态变更在同一个事务边界内提交避免“数据库改了缓存没删”。空结果也要缓存但时间要短通常 30 秒到 1 分钟防止有人用不存在的 Id 反复穿透到数据库。5. 常见问题排查权限、性能、部署的四类翻车点这一章讲的是上线前后最容易出问题的地方。下面四条都是我在同类项目里反复见到的按“现象—原因—解决”展开每条都给出可对照的代码或配置。5.1 越权访问前端隐藏按钮不等于后端拦截现象是普通编辑账号登录后页面上的删除按钮确实看不见但用接口工具直接调删除地址照样能删掉文章。原因很明确权限判断只写在了 Razor 视图里控制器和服务端没有二次校验。解决办法是把权限判断下沉到过滤器所有后台控制器统一挂上public class RequirePermissionAttribute : Attribute, IAsyncAuthorizationFilter { private readonly string _code; public RequirePermissionAttribute(string code) _code code; public async Task OnAuthorizationAsync(AuthorizationFilterContext context) { var checker context.HttpContext.RequestServices.GetRequiredServiceIPermissionChecker(); var userId context.HttpContext.User.GetUserId(); if (userId 0 || !await checker.HasPermissionAsync(userId, _code)) { context.Result new ForbidResult(); // 返回 403不要跳首页掩盖问题 } } }控制器方法上标注[RequirePermission(article.delete)]视图里的按钮显隐只是体验优化不再承担安全职责。数据范围也要在服务端过滤比如“部门管理员只能看本部门文章”这个条件要拼进查询语句不能靠前端传参。5.2 列表页越来越慢N1 查询与索引缺失现象是文章量过千以后后台列表页从一秒变成十几秒。原因通常有两层一是查询文章时带出了栏目导航属性EF Core 对每一行又发一条 SQL 查栏目几百行就是几百次往返二是列表按栏目和状态过滤但表上只有主键索引。解决顺序是先加索引再改查询写法var query _db.Articles.AsNoTracking() .Where(a !a.IsDeleted a.Status ArticleStatus.Published) .Where(a categoryIds.Contains(a.CategoryId)) // 含子孙栏目 .OrderByDescending(a a.IsTop).ThenByDescending(a a.PublishedAt) .Select(a new ArticleListItem { Id a.Id, Title a.Title, CoverUrl a.CoverUrl, CategoryName a.Category.Name, // 投影时一次 JOIN 取回 PublishedAt a.PublishedAt }); var total await query.CountAsync(); var items await query.Skip((page - 1) * size).Take(size).ToListAsync();AsNoTracking用于纯查询场景省掉变更跟踪开销Select投影让栏目名称通过一次 JOIN 拿到而不是访问导航属性触发懒加载。分页务必先Count再Skip/Take不要把所有数据取到内存里再分页。改完用 SQL 执行计划看一眼确认走了联合索引再收工。5.3 部署后样式丢失路径大小写与虚拟目录现象是本地调试一切正常发布到服务器后页面样式全丢控制台里 CSS 全是 404。原因多半是服务器文件系统区分大小写代码里写的是~/css/Site.css实际文件叫site.css或者站点部署在虚拟目录下用了以斜杠开头的绝对路径。解决办法是统一全小写命名静态资源引用一律用~开头的应用相对路径配 TagHelper部署前用脚本扫一遍资源引用的实际存在性# 发布后快速核对静态资源是否都能找到 find wwwroot -type f | awk -F/ {print tolower($0)} | sort | uniq -d这条命令能揪出仅大小写不同的重名文件提前在本地就暴露问题。虚拟目录部署时还要检查前端请求接口的基地址写死/api/...的会直接打到根站点上。5.4 上传报 500 与图片互相覆盖现象有两种一是上传时服务端返回 500日志里是“拒绝访问”二是后传的图片把先传的覆盖了。前者是应用池账号对上传目录没有写权限发布脚本要显式给目录授权后者是用了原始文件名且没做唯一化。上传目录不要放在网站根目录下可执行的位置最好单独一个目录并禁止脚本执行文件名按 3.3 的写法用 GUID 重命名。还有一点容易忽略清理旧图时只删数据库记录不删物理文件磁盘会越用越满删除逻辑里要带上物理文件删除并捕获文件不存在的异常。5.5 缓存没失效内容改了前台还是旧的现象是后台明明点了发布前台刷新还是旧标题。原因通常是只写缓存不删缓存或者删的键和写的键不是同一个。检查顺序是先看发布方法有没有调用清理再看缓存键的拼接参数是否一致比如列表页缓存键里带了栏目 Id清理时也要带。稳妥的做法是把同一类内容的键统一加前缀清理时按前缀批量移除而不是逐个猜键名。6. 验收与答辩一份能照着走的演示清单验收不是把功能点挨个点一遍而是按真实使用路径走通一条完整链路。我通常准备一张清单左边写验收项右边写通过标准答辩演示时按顺序走中间任何一步卡住都能定位到模块。验收项操作路径通过标准栏目管理新建两级栏目并调整排序前台地址可访问顺序与后台一致内容发布草稿→提交审核→发布状态流转正确审计日志有记录前台呈现打开栏目列表与文章详情伪静态地址正常移动端无横向滚动权限控制用低权限账号调删除接口返回 403数据未被修改性能基线首页与列表页各刷新十次首页响应 300ms 内列表翻页无明显延迟缓存一致性修改文章标题后刷新前台新标题立即生效演示脚本控制在八分钟内登录后台、建一个栏目、发一篇带封面的文章、走一次审核、切到前台看列表和详情、缩窄浏览器窗口看响应式、用低权限账号演示一次被拦截、最后打开审计日志。这个顺序本身就是一条完整的业务流程评委跟着看不会跳戏。答辩提问集中在几个方向为什么这样分层、权限怎么防越权、列表页慢怎么优化、缓存和数据库不一致怎么办、部署后出问题怎么排查。回答时别背概念直接指到代码位置和表结构上比如“越权拦截在权限过滤器里索引建在文章表的栏目加状态联合列上”。被问到没做的功能坦白说清取舍比硬编一个不存在的模块强。最后说个习惯每次交付前我都会用一个全新账号从零走一遍“建栏目到前台可见”的全流程不走后台现成的测试数据。血泪经验是测试数据往往掩盖了空状态和权限边界的问题而这两处恰恰是演示时最容易出问题的地方。希望这套结构能帮到你把门户网站的活干得更顺一点。本文还有配套的精品资源点击获取