ASP.NET值班管理系统：排班规则建模与EF Core领域设计

简介：这是一套基于ASP.NET Web Forms开发的值班管理信息系统，面向初学者与中小型单位信息化建设者，解决排班登记、人员调度、值班记录查询等日常行政管理痛点。系统采用B/S架构，适配Windows Server 2003+VS2010开发环境，后端依托Access 2010数据库，具备完整用户登录、部门管理、值班新增/编辑/统计、历史查询及权限控制等核心功能模块。压缩包共77个文件，含31个aspx页面（如Login.aspx、dutyList.aspx、OnDutyMine.aspx等构成完整业务流）、10个JavaScript脚本（含jQuery 1.4.1与WdatePicker日期控件）、10个GIF/JPG界面资源、6个核心DLL组件（涵盖DAL/BLL/Model分层逻辑）、以及mdb主数据库与Web.config配置文件，整体8.39MB，结构清晰、即装即用。已有492人学习下载，可直接部署调试，快速掌握ASP.NET表单开发、Access数据操作、前端交互集成及典型后台管理系统目录组织方式。

1. ASP.NET值班管理系统：为什么一个看似简单的排班需求，总在交接时出问题？

某高校后勤处上线过三版值班系统，前两版用Excel手工维护、微信群通知，第三版改用低代码平台搭建，结果半年后仍频繁出现“张工说没收到调班通知”“李老师重复排了两天夜班”“节假日排班表导出格式错乱”——直到他们把需求重新拆回最朴素的逻辑：谁、在什么时间、值守哪个岗位、是否已确认、异常如何追溯。ASP.NET值班管理系统不是炫技的Web应用，而是把排班规则、人员约束、通知闭环、操作留痕这四件事，在服务端稳稳托住的工程实践。它适合中小规模组织（30～200人）、有明确轮值周期（日/周/月）、需对接内部身份认证（如LDAP或统一登录）且对数据可审计性有硬性要求的场景。如果你正被“临时替班没人签收”“历史排班查不到原始记录”“导出Excel列宽崩塌”这类问题反复消耗，而不是纠结于前端动画有多酷，那这个标题指向的，就是你该沉下心来搭的那套底盘。

2. 从零建起核心模型：用Entity Framework Core定义值班域实体与关系

ASP.NET值班管理系统成败的第一关，不在界面多漂亮，而在领域模型能否准确承载业务语义。我们不抽象“排班”为泛泛的“任务”，而是拆解为四个强约束实体：Staff（人员）、Shift（班次）、DutySchedule（排班计划）、DutyRecord（执行记录）。它们之间不是简单的一对多，而是带业务规则的关联——比如一个班次可被多人申请，但同一时段同一岗位只允许一人生效；人员可被分配到多个班次，但必须满足“连续值班不超过24小时”的硬性限制。这种约束无法靠数据库外键完全表达，必须在应用层编码校验。下面用EF Core 7+ Code-First方式实现最小可行模型。

2.1 Staff与Shift：人员资质与班次属性的双向绑定

public class Staff { public int Id { get; set; } public string Name { get; set; } = string.Empty; public string EmployeeId { get; set; } = string.Empty; // 内部工号，用于对接HR系统 public bool IsActive { get; set; } = true; public DateTime? LastDutyDate { get; set; } // 用于计算连续值班间隔 // 导航属性：此人可胜任哪些班次（如夜班需持证） public ICollection<StaffShiftQualification> Qualifications { get; set; } = new List<StaffShiftQualification>(); } public class Shift { public int Id { get; set; } public string Code { get; set; } = string.Empty; // 如 NIGHT_001, DAY_AM public string Name { get; set; } = string.Empty; // 如“夜班（00:00-08:00）” public TimeSpan StartTime { get; set; } public TimeSpan EndTime { get; set; } public bool IsNightShift { get; set; } public int MaxConsecutiveDays { get; set; } = 2; // 此班次允许连续排班天数上限 public bool RequiresCertification { get; set; } // 是否需特殊资质 }

提示：StaffShiftQualification是连接表，含StaffId、ShiftId和ValidUntil字段，用于管理资质有效期。不要用ICollection<Shift>直接挂在Staff上——资质不是永久有效，必须可追溯失效时间。

2.2 DutySchedule：排班计划的版本化设计

排班不是一次性写死，而是按周期生成、允许人工微调、支持发布与回滚。因此DutySchedule不是单条记录，而是一组带版本号的快照：

public class DutySchedule { public int Id { get; set; } public int Version { get; set; } // 从1开始递增，每次重排生成新版本 public DateTime PeriodStart { get; set; } // 本计划覆盖起始日期（如2024-06-01） public DateTime PeriodEnd { get; set; } // 结束日期（如2024-06-30） public string Status { get; set; } = "Draft"; // Draft / Published / Archived public DateTime CreatedAt { get; set; } = DateTime.UtcNow; public string CreatedBy { get; set; } = string.Empty; // 操作人账号 // 导航：此计划下的所有具体排班项 public ICollection<DutyAssignment> Assignments { get; set; } = new List<DutyAssignment>(); } public class DutyAssignment { public int Id { get; set; } public int ScheduleId { get; set; } public int StaffId { get; set; } public int ShiftId { get; set; } public DateTime Date { get; set; } // 具体哪一天，如2024-06-15 public string Status { get; set; } = "Assigned"; // Assigned / Substituted / Cancelled public string Note { get; set; } = string.Empty; // 替班原因、特殊说明等 // 导航属性 public DutySchedule Schedule { get; set; } = null!; public Staff Staff { get; set; } = null!; public Shift Shift { get; set; } = null!; }

参数说明：Status字段是关键状态机起点。Assigned表示初始排定；Substituted表示已被替班（此时需关联DutyRecord.SubstitutionId）；Cancelled表示该班次取消（非删除，保留审计线索）。所有状态变更必须走服务层方法，禁止直接更新数据库字段。

2.3 DutyRecord：执行留痕与异常闭环的载体

值班不是排完就结束，而是要验证“人是否真到了岗”。DutyRecord记录每次实际执行情况，与DutyAssignment一对一绑定，但生命周期独立：

public class DutyRecord { public int Id { get; set; } public int AssignmentId { get; set; } public DateTime CheckInTime { get; set; } // 到岗时间，可为空（未打卡） public DateTime? CheckOutTime { get; set; } // 离岗时间 public string CheckInMethod { get; set; } = "Manual"; // Manual / QRCode / RFID public string Location { get; set; } = string.Empty; // 打卡地点，如“主控室A门禁” public string Remark { get; set; } = string.Empty; // 异常说明：“设备故障，延迟到岗15分钟” public bool IsConfirmed { get; set; } = false; // 是否经管理员二次确认 public DateTime? ConfirmedAt { get; set; } public string ConfirmedBy { get; set; } = string.Empty; // 关联原排班项与替班记录 public DutyAssignment Assignment { get; set; } = null!; public int? SubstitutionId { get; set; } // 若为替班，则指向另一条DutyRecord.Id }

逻辑说明：SubstitutionId是实现“替班链”的核心。当A替B值班，系统生成一条新DutyRecord，其SubstitutionId指向B的原始记录ID。这样查A的值班，能顺藤摸到B的原始安排，再查B的记录，若其SubstitutionId非空，说明B又被C替了——形成可追溯的链条。这是解决“谁替了谁、替了几次”的技术锚点。

3. 排班引擎落地：手写规则驱动的自动排班与人工干预接口

ASP.NET值班管理系统里，“自动排班”不是AI预测，而是将业务规则翻译成可执行的约束求解逻辑。我们不依赖第三方调度库（如Quartz.NET），因为排班规则高度定制化：某岗位夜班必须由满3年工龄者担任；护士长每周至少值一次白班；连续两天夜班后必须休息48小时……这些无法用通用调度器表达。正确做法是：用LINQ + 显式循环构建规则检查器，再封装为可测试的服务方法。

3.1 构建排班规则检查器（Rule Validator）

public interface IDutyRuleValidator { ValidationResult ValidateAssignment(Staff staff, Shift shift, DateTime date, IEnumerable<DutyRecord> history); } public class DefaultDutyRuleValidator : IDutyRuleValidator { private readonly IStaffRepository _staffRepo; private readonly IShiftRepository _shiftRepo; public DefaultDutyRuleValidator(IStaffRepository staffRepo, IShiftRepository shiftRepo) { _staffRepo = staffRepo; _shiftRepo = shiftRepo; } public ValidationResult ValidateAssignment(Staff staff, Shift shift, DateTime date, IEnumerable<DutyRecord> history) { var result = new ValidationResult(); // 规则1：人员当前是否在职 if (!staff.IsActive) { result.AddError("人员已离职，不可排班"); } // 规则2：资质是否有效（针对需认证的班次） if (shift.RequiresCertification) { var qual = staff.Qualifications.FirstOrDefault(q => q.ShiftId == shift.Id && q.ValidUntil >= date); if (qual == null) result.AddError($"人员缺少{shift.Name}所需资质，或资质已过期"); } // 规则3：连续值班检查（取近7天记录） var recentDuties = history .Where(r => r.StaffId == staff.Id && r.CheckInTime.HasValue) .OrderByDescending(r => r.CheckInTime.Value) .Take(7) .ToList(); if (recentDuties.Count > 0) { var lastDuty = recentDuties.First(); var hoursSinceLast = (date.Date - lastDuty.CheckInTime.Value.Date).TotalHours; if (hoursSinceLast < 48 && shift.IsNightShift && lastDuty.Assignment.Shift.IsNightShift) { result.AddError("连续夜班后未满48小时休息期"); } } // 规则4：班次容量检查（如某岗位最多2人同时在岗） var currentSameShift = history .Where(r => r.Assignment.Date == date && r.Assignment.ShiftId == shift.Id && r.CheckInTime.HasValue) .Count(); if (currentSameShift >= 2) // 假设该岗位上限为2 { result.AddError($"同班次在岗人数已达上限({currentSameShift}/2)"); } return result; } }

参数说明：ValidateAssignment方法接收待排人员、班次、日期及该人员近期值班记录。history参数必须由调用方传入（而非在方法内查询），这是为了单元测试可控性——你可以传入任意模拟数据验证规则。ValidationResult是自定义类，含Errors列表和IsValid属性，比抛异常更利于前端展示多条错误。

3.2 手动排班接口：AdminController中的原子操作

排班页面的“拖拽分配”背后，是严格事务控制的API。以下为AdminController中的核心动作，确保一次分配要么全部成功，要么全部回滚：

[HttpPost("assign")] public async Task<ActionResult> AssignToShift([FromBody] AssignRequest request) { // 1. 验证请求参数 if (!ModelState.IsValid) return BadRequest(ModelState); // 2. 获取当前最新发布的排班计划（必须是Published状态） var schedule = await _scheduleRepo.GetLatestPublishedAsync(request.PeriodStart, request.PeriodEnd); if (schedule == null) return NotFound("未找到对应周期的有效排班计划"); // 3. 加锁：防止并发修改同一计划 var lockKey = $"DutySchedule_{schedule.Id}"; if (!await _distributedLock.TryAcquireAsync(lockKey, TimeSpan.FromSeconds(30))) { return StatusCode(423, "排班计划正被他人编辑，请稍后重试"); } try { // 4. 执行规则校验（复用上节的Validator） var staff = await _staffRepo.GetByIdAsync(request.StaffId); var shift = await _shiftRepo.GetByIdAsync(request.ShiftId); var history = await _recordRepo.GetRecentByStaffAsync(request.StaffId, 7); var validationResult = _ruleValidator.ValidateAssignment(staff, shift, request.Date, history); if (!validationResult.IsValid) { return BadRequest(new { errors = validationResult.Errors }); } // 5. 创建新排班项（注意：不直接SaveChanges，先构造对象） var assignment = new DutyAssignment { ScheduleId = schedule.Id, StaffId = request.StaffId, ShiftId = request.ShiftId, Date = request.Date, Status = "Assigned" }; await _assignmentRepo.AddAsync(assignment); await _unitOfWork.SaveChangesAsync(); // 事务提交 return Ok(new { success = true, assignmentId = assignment.Id }); } finally { await _distributedLock.ReleaseAsync(lockKey); // 必须释放锁 } } public class AssignRequest { public int StaffId { get; set; } public int ShiftId { get; set; } public DateTime Date { get; set; } public DateTime PeriodStart { get; set; } public DateTime PeriodEnd { get; set; } }

逻辑说明：这里用了分布式锁（如Redis Lock）而非数据库行锁，因为排班操作可能跨多个表（DutySchedule、DutyAssignment、DutyRecord），且需防止不同服务器实例同时修改。TryAcquireAsync超时设为30秒是经验值——人工操作不可能卡这么久，超时即提示“正在编辑”，避免用户误以为系统卡死。

3.3 自动排班批处理：后台服务中的规则优先级调度

对于月度排班，人工逐个分配效率太低。我们用IHostedService实现后台排班任务，按规则优先级顺序执行：

public class AutoDutyScheduler : IHostedService, IDisposable { private Timer _timer; private readonly IDutyRuleValidator _validator; private readonly IAssignmentService _assignmentService; public Task StartAsync(CancellationToken cancellationToken) { // 每日凌晨2点触发（避开业务高峰） _timer = new Timer(DoWork, null, TimeSpan.Zero, TimeSpan.FromHours(24)); return Task.CompletedTask; } private async void DoWork(object state) { try { // 1. 获取下月待排周期（如7月1日-7月31日） var nextMonth = DateTime.Now.AddMonths(1); var periodStart = new DateTime(nextMonth.Year, nextMonth.Month, 1); var periodEnd = periodStart.AddMonths(1).AddDays(-1); // 2. 生成新排班计划（Version自增） var newSchedule = await _scheduleService.CreateNewVersionAsync(periodStart, periodEnd); // 3. 按岗位分组，对每个岗位执行规则调度 var shifts = await _shiftRepo.GetAllAsync(); foreach (var shift in shifts.Where(s => s.IsActive)) { await ScheduleShiftForPeriod(shift, newSchedule, periodStart, periodEnd); } } catch (Exception ex) { _logger.LogError(ex, "自动排班任务失败"); } } private async Task ScheduleShiftForPeriod(Shift shift, DutySchedule schedule, DateTime start, DateTime end) { // 核心逻辑：遍历每一天，为该班次找合适人员 for (var date = start; date <= end; date = date.AddDays(1)) { // 获取该班次下所有可用人员（按工龄、资质等预筛选） var candidates = await _staffRepo.GetQualifiedCandidatesAsync(shift.Id, date); // 按规则打分：工龄高者得分+，近期值班少者得分+，夜班次数少者得分+ var scored = candidates .Select(s => new { Staff = s, Score = CalculateScore(s, shift, date, candidates) }) .OrderByDescending(x => x.Score) .FirstOrDefault(); if (scored != null) { // 尝试分配（会再次调用ValidateAssignment做最终校验） await _assignmentService.AssignAsync(scored.Staff.Id, shift.Id, date, schedule.Id); } } } }

参数说明：CalculateScore是业务敏感函数，需根据组织实际调整权重。例如某医院规定“护师职称以上者夜班分+5，主管护师+10”，这部分逻辑应抽离为配置项，而非硬编码。我们通常将其存为JSON配置表，运行时加载，避免改代码发版。

4. 常见问题排查：5个让值班系统上线后半夜被call的真实坑

ASP.NET值班管理系统上线后最常被紧急呼叫的，往往不是功能缺失，而是某些边界场景下数据状态错乱、通知失联或权限失控。以下是我在三个不同组织部署中踩过的5个典型坑，按“现象→原因→解决”结构整理，每一条都附带可立即验证的检查命令。

4.1 现象：排班表导出Excel时，日期列显示为数字（如45123）而非“2024/06/15”

原因：ASP.NET Core MVC默认使用System.Text.Json序列化DateTime，导出时未指定日期格式，前端JavaScript解析后转为毫秒时间戳，Excel识别为数值。更隐蔽的是，部分IE内核浏览器会强制将数字列转为科学计数法，导致日期彻底不可读。

解决：

• 后端导出API中，用NPOI库直接生成Excel流，而非返回JSON再前端渲染：

// 在ExportController中 public async Task<IActionResult> ExportSchedule(int scheduleId) { var assignments = await _assignmentRepo.GetByScheduleIdAsync(scheduleId); var stream = new MemoryStream(); using (var workbook = new XSSFWorkbook()) // .xlsx格式 { var sheet = workbook.CreateSheet("排班表"); var headerRow = sheet.CreateRow(0); headerRow.CreateCell(0).SetCellValue("日期"); headerRow.CreateCell(1).SetCellValue("姓名"); headerRow.CreateCell(2).SetCellValue("班次"); int rowNum = 1; foreach (var a in assignments) { var row = sheet.CreateRow(rowNum++); row.CreateCell(0).SetCellValue(a.Date); // NPOI自动识别DateTime类型 row.CreateCell(1).SetCellValue(a.Staff.Name); row.CreateCell(2).SetCellValue(a.Shift.Name); } workbook.Write(stream); } stream.Position = 0; return File(stream, "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", $"值班表_{scheduleId}.xlsx"); }

验证命令：用Postman调用GET /api/export/schedule/123，检查响应头Content-Type是否为application/vnd.openxmlformats-officedocument.spreadsheetml.sheet，下载文件后用Excel打开确认日期格式。

4.2 现象：管理员修改了某天的排班，但相关人员微信/短信通知未发出

原因：通知服务（如短信网关、企业微信Bot）调用是异步Fire-and-Forget模式，未做失败重试与死信队列。当网关临时不可用，消息直接丢失，且无任何告警。

解决：

• 通知逻辑改为“先落库，再异步发送”：

// 新增Notification表 public class Notification { public int Id { get; set; } public string TargetType { get; set; } = "WeCom"; // WeCom / SMS / Email public string TargetId { get; set; } = string.Empty; // 企业微信userid / 手机号 public string Content { get; set; } = string.Empty; public string Status { get; set; } = "Pending"; // Pending / Sent / Failed public DateTime CreatedAt { get; set; } = DateTime.UtcNow; public DateTime? SentAt { get; set; } public string ErrorMessage { get; set; } = string.Empty; } // 在AssignToShift成功后，插入Notification记录 await _notificationRepo.AddAsync(new Notification { TargetType = "WeCom", TargetId = staff.WeComUserId, Content = $"您被排定于{request.Date:yyyy-MM-dd}值{shift.Name}，请准时到岗" }); await _unitOfWork.SaveChangesAsync(); // 启动后台任务扫描Pending通知（每分钟一次） services.AddHostedService<NotificationSenderService>();

验证命令：手动在Notification表中插入一条Status='Pending'记录，观察1分钟后Status是否变为Sent，并检查企业微信是否收到消息。若失败，ErrorMessage字段应有明确报错（如“userid不存在”）。

4.3 现象：某员工反馈“我明明休年假，系统还给我排了班”

原因：休假数据来自HR系统，但值班系统未做定时同步，或同步时未处理“休假单审批中”状态，将待审批单当作已批准单同步过来。

解决：

• 休假同步必须带状态过滤，并增加人工审核开关：

// HR同步Job中，只同步Approved状态的休假单 var approvedLeaves = await _hrApiClient.GetLeavesAsync(DateTime.Now.AddMonths(-3), DateTime.Now.AddMonths(3), status: "Approved"); foreach (var leave in approvedLeaves) { // 检查该员工在排班周期内是否有冲突 var conflictAssignments = await _assignmentRepo.GetByStaffAndDateRangeAsync( leave.StaffId, leave.StartDate, leave.EndDate); if (conflictAssignments.Any()) { // 自动标记为Conflict，等待管理员处理（非自动取消！） foreach (var a in conflictAssignments) { a.Status = "VacationConflict"; a.Note += $"; 冲突休假单:{leave.LeaveId}"; } } }

验证命令：在HR系统提交一条“年假申请（待审批）”，检查值班系统DutyAssignment表中对应日期的记录Status是否仍为Assigned，而非误标为VacationConflict。

4.4 现象：导出的排班表PDF中，中文显示为方块（□□□）

原因：iTextSharp或QuestPDF等PDF库默认字体不支持中文，未显式设置中文字体路径。

解决：

• 使用QuestPDF时，全局注册思源黑体（免费可商用）：

// Program.cs中 Document.SetFontDirectory("wwwroot/fonts"); // 放置simsun.ttc或SourceHanSansSC-Regular.otf Document.SetDefaultFontFamily("Source Han Sans SC"); // 思源黑体简

• 或在PDF生成代码中显式指定：

var document = Document.Create(container => { container.Page(page => { page.Size(PageSizes.A4); page.Margin(2, Unit.Centimetre); page.DefaultTextStyle(x => x.FontSize(12).FontFamily("Source Han Sans SC")); // ...其余内容 }); });

验证命令：生成PDF后，用Adobe Acrobat打开，右键“属性”→“字体”，确认列表中包含Source Han Sans SC且状态为“嵌入子集”。

4.5 现象：管理员A修改了排班，但管理员B刷新页面后看到的仍是旧数据

原因：前端Vue/React组件未监听WebSocket或SignalR推送，且HTTP缓存头设置不当，浏览器直接返回304（Not Modified）。

解决：

• 后端API添加防缓存头：

// 在Startup.cs或Program.cs中 app.Use(async (context, next) => { if (context.Request.Path.StartsWithSegments("/api")) { context.Response.Headers["Cache-Control"] = "no-cache, no-store, must-revalidate"; context.Response.Headers["Pragma"] = "no-cache"; context.Response.Headers["Expires"] = "0"; } await next(); });

• 前端使用SignalR接收实时更新：

// Vue组件中 const connection = new HubConnectionBuilder() .withUrl("/dutyhub") // 对应DutyHub类 .build(); connection.on("AssignmentUpdated", (assignment: DutyAssignment) => { // 找到本地数组中id相同的项，替换为新对象 const index = this.assignments.findIndex(a => a.id === assignment.id); if (index !== -1) { this.assignments.splice(index, 1, assignment); } }); await connection.start();

验证命令：用两个浏览器标签页分别登录管理员A、B账号，A修改某条排班，B页面应1秒内自动更新，而非手动F5。

5. 权限与审计：用ASP.NET Core Identity + 自定义策略实现细粒度控制

值班管理系统的权限不能只停留在“登录即管理员”，必须精确到“谁可以编辑6月排班”“谁只能查看自己班次”“谁有权审批替班申请”。ASP.NET Core Identity提供基础框架，但需结合IAuthorizationHandler与资源型策略（Resource-based Authorization）才能落地。我们不采用Role-Based（RBAC）的粗粒度方案，而是用Policy-Based（PBAC）绑定具体资源实例。

5.1 定义资源型授权策略：DutyScheduleOwnershipRequirement

核心是判断当前用户是否对某个DutySchedule拥有编辑权。这取决于：1）用户角色（如“排班管理员”）；2）该计划的周期是否在用户管辖范围内（如某科室主任只能管本科室排班）；3）计划状态（Draft可编辑，Published仅限特定人修改）。

public class DutyScheduleOwnershipRequirement : IAuthorizationRequirement { public DutyScheduleOwnershipRequirement() { } } public class DutyScheduleOwnershipHandler : AuthorizationHandler<DutyScheduleOwnershipRequirement, DutySchedule> { private readonly IUserContext _userContext; // 封装当前用户信息（含部门、角色等） private readonly IScheduleRepository _scheduleRepo; public DutyScheduleOwnershipHandler(IUserContext userContext, IScheduleRepository scheduleRepo) { _userContext = userContext; _scheduleRepo = scheduleRepo; } protected override async Task HandleRequirementAsync(AuthorizationHandlerContext context, DutyScheduleOwnershipRequirement requirement, DutySchedule resource) { if (context.User == null || resource == null) return; // 1. 检查是否为超级管理员（跳过所有检查） if (await _userContext.IsInRoleAsync("SuperAdmin")) { context.Succeed(requirement); return; } // 2. 检查是否为排班管理员（角色权限） var isAdmin = await _userContext.IsInRoleAsync("DutyAdmin"); if (!isAdmin) return; // 3. 检查该计划是否属于用户管辖部门（假设用户有DepartmentId） var scheduleDept = await _scheduleRepo.GetDepartmentIdByScheduleAsync(resource.Id); if (scheduleDept != _userContext.DepartmentId) return; // 4. 检查计划状态：Draft可编辑，Published需额外审批权限 if (resource.Status == "Published") { var canPublishEdit = await _userContext.IsInRoleAsync("PublishEditor"); if (!canPublishEdit) return; } context.Succeed(requirement); } }

逻辑说明：HandleRequirementAsync的第三个参数DutySchedule resource是关键——它代表被访问的具体资源实例（如ID=123的排班计划），而非泛泛的“排班模块”。这样就能做实例级判断，比如“张主任只能编辑ID=123的计划，因为123属于外科，而他是外科主任”。

5.2 在Controller中应用资源策略

传统[Authorize(Roles="DutyAdmin")]只能控制模块入口，无法区分具体资源。必须用IAuthorizationService在Action内做运行时检查：

[ApiController] [Route("api/[controller]")] public class DutySchedulesController : ControllerBase { private readonly IAuthorizationService _authorizationService; private readonly IScheduleRepository _scheduleRepo; public DutySchedulesController(IAuthorizationService authorizationService, IScheduleRepository scheduleRepo) { _authorizationService = authorizationService; _scheduleRepo = scheduleRepo; } [HttpGet("{id}")] public async Task<ActionResult<DutySchedule>> Get(int id) { var schedule = await _scheduleRepo.GetByIdAsync(id); if (schedule == null) return NotFound(); // 运行时检查：当前用户是否有权查看此计划 var authResult = await _authorizationService.AuthorizeAsync(User, schedule, "DutyScheduleViewPolicy"); if (!authResult.Succeeded) return Forbid(); return Ok(schedule); } [HttpPut("{id}")] public async Task<ActionResult> Update(int id, [FromBody] UpdateScheduleRequest request) { var schedule = await _scheduleRepo.GetByIdAsync(id); if (schedule == null) return NotFound(); // 运行时检查：当前用户是否有权编辑此计划 var authResult = await _authorizationService.AuthorizeAsync(User, schedule, "DutyScheduleEditPolicy"); if (!authResult.Succeeded) return Forbid(); // 执行更新逻辑... await _scheduleRepo.UpdateAsync(schedule); return NoContent(); } }

参数说明："DutyScheduleEditPolicy"是注册的策略名，需在Program.cs中配置：

builder.Services.AddAuthorization(options => { options.AddPolicy("DutyScheduleEditPolicy", policy => policy.RequireAuthenticatedUser() .RequireClaim("scope", "duty.write") // 需OAuth scope .AddRequirements(new DutyScheduleOwnershipRequirement())); });

5.3 审计日志：记录每一次关键操作的完整上下文

权限控制之后，必须留下不可抵赖的操作痕迹。我们不依赖数据库触发器（难调试、难扩展），而是用MediatR行为管道（Behavior Pipeline）统一拦截所有写操作：

public class AuditLoggingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse> where TRequest : notnull { private readonly IAuditLogService _auditLog; private readonly IUserContext _userContext; public AuditLoggingBehavior(IAuditLogService auditLog, IUserContext userContext) { _auditLog = auditLog; _userContext = userContext; } public async Task<TResponse> Handle(TRequest request, RequestHandlerDelegate<TResponse> next) { var response = await next(); // 只记录明确标记为需审计的请求 if (request is IRequireAudit auditRequest) { var auditEntry = new AuditLogEntry { UserId = _userContext.UserId, UserName = _userContext.UserName, Action = auditRequest.ActionName, TargetType = auditRequest.TargetType, TargetId = auditRequest.TargetId?.ToString(), RequestData = JsonConvert.SerializeObject(request), Timestamp = DateTime.UtcNow, IpAddress = _userContext.IpAddress }; await _auditLog.SaveAsync(auditEntry); } return response; } } // 标记接口 public interface IRequireAudit { string ActionName { get; } string TargetType { get; } object TargetId { get; } } // 在AssignCommand中实现 public class AssignCommand : IRequest<bool>, IRequireAudit { public int StaffId { get; set; } public int ShiftId { get; set; } public DateTime Date { get; set; } public string ActionName => "AssignToShift"; public string TargetType => "DutyAssignment"; public object TargetId => $"{StaffId}_{ShiftId}_{Date:yyyyMMdd}"; }

验证技巧：部署后，手动执行一次排班分配，然后查AuditLogEntry表，确认RequestData字段是否完整记录了StaffId、ShiftId、Date，且IpAddress为真实客户端IP（非127.0.0.1）。这是应对“谁在何时改了什么”的唯一法律依据。

6. 生产就绪 checklist：从开发到上线的7个必做动作

ASP.NET值班管理系统不是Demo，上线即承担真实业务连续性。我给自己立了一条铁律：任何新功能合并前，必须通过这份checklist。它不追求理论完备，只问“今天凌晨三点被call，我能快速定位吗？”——以下是7个血泪经验凝结的动作，每个都对应一个真实翻车现场。

6.1 数据库迁移脚本必须带回滚（Down）且经人工验证

第一次上线时，我写了Up脚本新增DutyRecord.SubstitutionId字段，却忘了写Down。后来发现字段类型错了（应为int?而非int），想回退时只能手动删列——结果误删了生产数据。现在我的Migrations目录下，每个Up必配Down，且Down脚本第一行加注释：

// WARNING: Down操作会清空DutyRecord.SubstitutionId历史数据，仅用于开发环境重置 // 生产环境严禁执行！如需修复，请联系DBA执行ALTER COLUMN protected override void Down(MigrationBuilder migrationBuilder) { migrationBuilder.DropColumn( name: "SubstitutionId", table: "DutyRecord"); }

执行动作：在本地SQL Server中新建空库，执行dotnet ef migrations script --idempotent生成全量脚本，人工通读一遍，确认所有DROP操作前都有IF EXISTS，且Down脚本无危险操作。

6.2 所有外部依赖必须配置超时与熔断，且超时值显式写死

曾因短信网关响应慢（平均8秒），导致排班API整体超时（默认30秒），引发连锁雪崩。现在所有HttpClient都单独配置：

// Program.cs中 builder.Services.AddHttpClient<ISmsService, SmsService>(client => { client.BaseAddress = new Uri(builder.Configuration["Sms:BaseUrl"]); }) .ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler { // 显式设置DNS解析、连接、请求超时 PooledConnectionLifetime = TimeSpan.FromMinutes(5), }) .AddPolicyHandler(Policy.TimeoutAsync<HttpResponseMessage>(TimeSpan.FromSeconds( <p> <a href="https://download.csdn.net/download/ptqslong/10321210" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>