ASP.NET Core实战：构建完整点餐系统的技术解析

1. 项目需求梳理与整体规划

1.1 从食堂排队想到的点餐需求

做这个 ASP.NET 点餐系统，最初的动机特别朴素——我们公司楼下食堂一到饭点就排队，12点下班12点40才能吃上饭。我当时就想，能不能做一个简单的在线点餐系统，让同事们提前把菜选好，食堂按订单备餐，到点直接取餐走人。

这个念头一旦萌生，就收不住了。我盘了一下自己手头的技术储备，恰好那段时间刚把 ASP.NET Core 的基础知识过了一遍，一直没找到合适的练手项目，点餐系统这种业务逻辑清晰、前后端交互频繁、又带支付和权限管理的场景，简直是天然的实战题材。更重要的是，它覆盖了 Web 开发里最常用的一整套能力：增删改查、状态流转、用户认证、并发扣库存、订单幂等，做完一个点餐系统，基本就把一个完整业务系统的骨架摸透了。

所以如果你现在问我，初学者或者刚转行的朋友选什么项目练手最划算，我的答案一直是：点餐系统。它不像电商系统那么庞大，但也不像 Todo List 那种玩具项目一样浅薄，难度刚好卡在“跳一跳够得着”的位置。

1.2 功能拆解：顾客端、商家端、管理端

需求想清楚之后，我没有直接上手写代码，而是先花了三天时间把功能清单和页面草图梳理了一遍。点餐系统看着小，实际上拆开来看有三个完全不同的使用角色，每个角色关注的点都不一样：

• 顾客端：浏览菜品、按分类筛选、加入购物车、下单、查看历史订单、取消未接单的订单。
• 商家端：菜品管理（上架、下架、改价、改描述）、订单管理（接单、出餐、完成）、查看当日营收统计。
• 管理端：用户管理、角色分配、全站订单监控、数据看板。

三个端共用一套数据库和 API，但前端页面和权限策略完全不同。这里最关键的拆解思路是：把订单状态机提前定义好，否则后面写业务逻辑的时候一定会拧巴。我最后定的状态流是：待支付 → 待接单 → 制作中 → 待取餐 → 已完成，另加一个“已取消”作为终态，供顾客在待接单之前主动取消，或者商家在接单前拒绝。

状态流转的规则是：只有特定角色在特定状态下才能执行特定动作，比如顾客只能取消“待支付”和“待接单”状态的订单，商家只能把“待接单”转为“制作中”，管理员可以看所有数据但不能改订单状态。这个状态机是整个系统最核心的骨架，后续所有代码都是围绕它展开的。

1.3 项目规划和里程碑拆解

项目从动手到完成用了大概四周，基本是利用工作日的晚上和周末来写。我给自己设了几个里程碑，每个里程碑都有明确的交付物：

• 第一周：需求梳理 + 技术选型 + 数据库设计，产出完整的建表 SQL 和 ER 图。
• 第二周：搭建 ASP.NET Core 项目骨架，完成基于 Cookie 的身份认证和三个角色的权限控制，实现菜品 CRUD。
• 第三周：实现购物车、下单、订单状态流转这三个核心业务模块，联调前后端接口。
• 第四周：补全商家端的订单处理流程、管理端的数据看板，做整体联调和部署上线。

这样拆完以后，整个项目的压力就分散了，每天晚上写一点都能看到进度，不容易产生挫败感。如果你也想做类似的项目，我强烈建议把“数据库设计”单独拿出来作为第一个里程碑，不要跳过去直接写代码——我在这个项目里吃过的最大苦头，恰恰是中途改表结构，后面会专门讲这个坑。

2. 技术选型：为什么选 ASP.NET Core

2.1 方案对比：Web Forms、MVC 还是 Core

标题里的“ASP.NET”其实是个大概念，它下面有好几条技术路线。老一辈开发者可能用过 Web Forms，那套控件拖拽的开发模式对于快速做后台管理系统确实方便，但前后端逻辑耦合得厉害，HTML 和服务器逻辑缠在一起，维护起来相当痛苦。而传统的 ASP.NET MVC 架构清晰了不少，但也有个硬伤：跨平台能力弱，只能跑在 Windows + IIS 上。

这次我直接选了 ASP.NET Core，原因很明确：

• 跨平台：开发时在 macOS 上跑，部署到 Windows 服务器，完全不冲突，开发体验很舒服。
• 性能好：ASP.NET Core 在 TechEmpower 的 Web 框架性能测试里常年排第一梯队，比老一代 ASP.NET 快了好几倍。
• 依赖注入原生集成：构造函数注入直接用，不用折腾 Autofac（当然真要用 Autofac 也支持）。
• 统一的中间件管道：请求处理流程完全可控，想加日志、加认证、加异常处理，往管道里塞中间件就行，理解起来很直观。

版本选的是 .NET 6，这个版本是 LTS（长期支持），生态成熟，踩坑资料也多，适合实战项目。如果你现在新建项目，可以用 .NET 8，API 差别不大，基本逻辑完全通用。

2.2 前端方案：服务端渲染还是前后端分离

前端这块我纠结了很久。网上到处都在聊前后端分离，似乎不用 Vue/React 就落伍了。但冷静分析后我决定采用 ASP.NET Core MVC + Razor 视图 + 局部 JavaScript 的方案，也就是服务端渲染为主，局部交互用 fetch 调接口。

为什么这么选？一是这个项目的数据实时性要求没那么高，服务端渲染的首次加载速度反而更快，因为 HTML 是直接生成的，不需要浏览器再跑一遍 JS 框架去渲染；二是 Razor 视图和后台代码配合紧密，基于角色的页面权限控制可以直接在服务端做，不需要前端额外处理路由守卫；三是我当时对 Vue 的熟练度还不够，硬上前后端分离会同时增加调试和部署的复杂度。

不过我也做了一部分的“伪前后端分离”——购物车和下单相关接口设计成纯 Web API，前端用 fetch 调用，这为以后如果要把前端重构成 Vue/React 留好了余地。这个折中方案在实际开发中很舒服，页面跳转交给 MVC 路由，局部刷新交给 fetch，各干各的互不干扰。

2.3 项目结构规划

ASP.NET Core 项目里，代码的组织方式直接影响后续维护的体验。我采用了经典的三层结构外加仓储模式，按功能而不是按技术层来分包：

• Controllers：接收 HTTP 请求，绑定参数，调用服务层，返回视图或 JSON。
• Services：业务逻辑都放这里，比如下单事务、库存扣减、订单状态校验。
• Repositories：数据库访问封装，所有 EF Core 的 DbContext 操作不会泄漏到 Service 层。
• Models：实体类、DTO（数据传输对象）、视图模型（ViewModel）分开存放。
• Data：DbContext 和数据库初始化逻辑。

刚开始写的时候容易犯一个毛病，就是把业务逻辑全塞进 Controller，Controller 动辄几百行，后面要改一个规则得分好几个文件找。当时写订单取消的逻辑，就遇到这种情况——先是在 Controller 里写了取消方法，后来又要在后台管理页面复用，没办法只能把逻辑抽到 Service 层。所以如果你现在起步，建议从一开始就把 Service 层立起来，哪怕前期看似多写了几行代码，后面改需求的时候会非常感谢当初的自己。

3. 数据库设计与 EF Core 实践

3.1 核心表结构设计思路

数据库设计是整个项目的基石，直接决定了后面写业务代码的顺畅程度。我设计的第一版表结构里有 8 张表：用户表（User）、角色表（Role）、菜品分类表（Category）、菜品表（Dish）、购物车表（CartItem）、订单表（Order）、订单明细表（OrderItem）、系统配置表（Setting）。

这里重点说几个当时反复推敲过的设计决策：

第一个是用户表要不要和顾客/商家分开。 我做的是单用户表加角色字段的方案，也就是一个 User 包含所有账号，通过 RoleType 区分是顾客还是商家。这样做的好处是将来一个人可以既是商家又是顾客（比如店主自己也在店里点餐），只用一套登录体系就够了。

第二个是购物车表的设计。 最简方案是不建表，直接把购物车数据放 Session 里。但我选择了建表，原因有两个：一是 Session 默认存在服务器内存里，用户量上来以后会吃内存；二是购物车建表以后，用户可以跨设备同步购物车，虽然这个项目没做多端同步，但保留了扩展能力。购物车表的核心字段是 UserId、DishId、Quantity、CreateTime，逻辑上每个用户每道菜最多一条记录，重复加购时做数量累加。

第三个是订单号生成策略。 订单表的主键我用了自增 int，但同时设了一个订单号字段，格式是 yyyyMMddHHmmss + 4位随机数。这样做的好处是给用户看的订单号短而整齐，排查问题时用订单号比用自增 ID 直观得多。自增 ID 一旦暴露，竞争对手能通过订单编号的差值推算你的日订单量，虽然个人项目无伤大雅，但养成这个习惯没坏处。

3.2 关键外键关系和级联策略

表的关联关系是整个数据库的灵魂。我画 ER 图的时候，把重点关系列了出来：

• User 和 Role：多对多，但简化成 User 表带一个 RoleId 外键（因为默认一个用户只有一个角色，暂不支持多角色）。
• Category 和 Dish：一对多，一个分类下有多道菜。
• Dish 和 CartItem：一对多，一个菜品可以被多个用户加入购物车。
• Order 和 OrderItem：一对多，一个订单包含多个订单明细。
• User 和 Order：一对多，一个用户可以有多个订单。

级联删除策略我统一设置了 Restrict（限制），也就是有关联数据时禁止直接删除父表记录。比如一个分类下还有菜品，就不允许直接删除这个分类；一个菜品被加进了购物车，就不能直接删除菜品。这是很多新手容易忽略的地方——不设级联策略，删除时要么报错要么产生脏数据；全设成 Cascade 又容易误删一大片。

3.3 使用 EF Core Fluent API 配置实体关系

EF Core 有两种实体配置方式：数据注解（Attribute）和 Fluent API。数据注解写起来快，但复杂的表关系没法用 Attribute 优雅表达，所以我全部用了 Fluent API，统一写在 DbContext.OnModelCreating 里。举个例子，Order 和 OrderItem 的配置是这样写的：

csharp复制protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // 订单表
    modelBuilder.Entity<Order>(entity =>
    {
        // 订单号唯一索引，防止并发下重复
        entity.HasIndex(o => o.OrderNo).IsUnique();
        
        // 配置订单和订单明细的一对多关系
        entity.HasMany(o => o.Items)
              .WithOne(i => i.Order)
              .HasForeignKey(i => i.OrderId)
              .OnDelete(DeleteBehavior.Restrict);
    });

    // 订单明细表
    modelBuilder.Entity<OrderItem>(entity =>
    {
        // 订单明细和菜品是一对多
        entity.HasOne(i => i.Dish)
              .WithMany()
              .HasForeignKey(i => i.DishId)
              .OnDelete(DeleteBehavior.Restrict);
    });

    // 购物车表：同一个用户对同一个菜品只能有一条记录
    modelBuilder.Entity<CartItem>(entity =>
    {
        entity.HasIndex(c => new { c.UserId, c.DishId }).IsUnique();
    });
}

这里有几个细节值得注意：

• 订单号加唯一索引是必须的，因为生成订单号的时候用的是时间戳加随机数，理论上极小概率会冲突，加唯一索引相当于last line of defense，真冲突了代码抛异常也比静默覆盖好。
• 删除行为统一 Restrict，是为了防止误删波及。比如 Dish 被 OrderItem 引用时，如果有人不小心删了菜品，级联删除会把历史订单明细一起删掉，这在业务上是严重事故。
• 购物车表的联合唯一索引很有用，它保证“一个用户针对一个菜品最多一条加购记录”，不需要在代码里先查询再判断是新增还是累加，直接让数据库帮我们保证了这个不变量。

3.4 中途改表引发的连锁修改

这块必须单独拿出来说。我最初设计订单表的时候，只设计了“状态”字段和“下单时间”，没设计“支付时间”和“完成时间”。结果做到商家端的时候发现，老板想看每个菜品的出餐耗时，才发现缺少“开始制作时间”这个字段。

往一个已经有数据的表里加字段，EF Core 的做法是新增 Migration。步骤倒是不复杂：

bash复制dotnet ef migrations add AddOrderTimeFields
dotnet ef database update

但麻烦的是代码侧的连锁反应。订单详情页要展示所有时间节点，OrderViewModel 要加字段，前端页面的表格要加两列，订单导出的 Excel 也要加列。我因为最初没设计这个字段，前后总共改了 7 个文件。所以后来我总结出一个经验：时间类字段在订单表里宁可多配几个，比如 CreatedAt、PaidAt、AcceptedAt、CompletedAt、CancelledAt，一开始都建好，用不上就空着，总比后面改表舒服。

4. 后端核心功能实现

4.1 基于 Cookie 的身份认证与角色授权

ASP.NET Core 里做登录认证，最基础也是最常用的方式是 Cookie 身份认证。用户登录成功后，服务器生成一个加密的 Cookie 存在浏览器里，后续每个请求都带着这个 Cookie，服务端解密后就知道是谁在请求。

Startup 里的配置大概是这样的：

csharp复制builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.LoginPath = "/Account/Login";
        options.AccessDeniedPath = "/Account/Forbidden";
        options.ExpireTimeSpan = TimeSpan.FromHours(8);
        options.SlidingExpiration = true;
    });

SlidingExpiration 这个配置我要特别说一下：它的作用是用户在持续操作时自动续期 Cookie，避免用到一半被强制下线。但小心点，它和 ExpireTimeSpan 配合使用时，如果设置了固定的绝对过期时间可能不生效。对于点餐系统这种使用频率不高的工具类应用，8 小时过期加滑动续期是合理的配置。

角色授权的写法也很简单，在 Controller 或 Action 上打特性标签就行：

csharp复制[Authorize(Roles = "Admin")]
public IActionResult Dashboard()
{
    return View();
}

还有一种情况是页面上的某个按钮只对特定角色显示，这种不能只靠 Controller 端控制，还得在 Razor 视图里判断角色。当时做商家端的“接单”按钮时，就用到了这个：

html复制@if (User.IsInRole("Merchant"))
{
    <button class="btn btn-success" onclick="acceptOrder(@order.Id)">接单</button>
}

顺便提一句，千万不要在前端用“页面隐藏”代替服务端权限校验。前端隐藏只是 UI 策略，服务端校验才是安全底线。如果有人直接构造 API 请求，跨过前端调用接单接口，那服务端就得判断当前用户有没有权限。我在所有涉及订单操作的接口里都加了角色校验，这是这个项目的安全底线。

4.2 购物车与下单的事务处理

购物车和下单是一对紧耦合的模块。购物车的实现要点在于数量累加和越界控制，下订单则要处理事务一致性和库存并发减扣。

先看购物车的核心逻辑。用户点“加入购物车”时，后端拿到 DishId，先查一下购物车表里有没有这个用户的这道菜记录，有就累加数量，没有就新建记录。但这里有个并发隐患：如果用户连点两次“加入购物车”，两个请求同时查到没有记录，就可能插入两条重复记录。联合索引在这里兜了底，数据库直接拒绝第二条插入，代码捕获异常后再改为更新数量。

csharp复制public async Task AddToCartAsync(int userId, int dishId, int quantity)
{
    var cartItem = await _db.CartItems
        .FirstOrDefaultAsync(c => c.UserId == userId && c.DishId == dishId);

    if (cartItem == null)
    {
        cartItem = new CartItem
        {
            UserId = userId,
            DishId = dishId,
            Quantity = quantity,
            CreateTime = DateTime.Now
        };
        _db.CartItems.Add(cartItem);
    }
    else
    {
        cartItem.Quantity += quantity;
    }

    await _db.SaveChangesAsync();
}

下单是事务的典型场景，一个订单包含主表和明细表，主表插入了，明细表插入失败怎么办？数据库必须回滚。EF Core 里最简单的方式是 IDbContextTransaction：

csharp复制public async Task<bool> CreateOrderAsync(int userId, List<CartItem> cartItems)
{
    using var transaction = await _db.Database.BeginTransactionAsync();
    try
    {
        var order = new Order
        {
            OrderNo = GenerateOrderNo(),
            UserId = userId,
            TotalAmount = cartItems.Sum(i => i.Dish.Price * i.Quantity),
            Status = OrderStatus.PendingPayment,
            CreatedAt = DateTime.Now
        };
        _db.Orders.Add(order);
        await _db.SaveChangesAsync();

        foreach (var item in cartItems)
        {
            _db.OrderItems.Add(new OrderItem
            {
                OrderId = order.Id,
                DishId = item.DishId,
                DishName = item.Dish.Name,
                UnitPrice = item.Dish.Price,
                Quantity = item.Quantity,
                Subtotal = item.Dish.Price * item.Quantity
            });
        }
        await _db.SaveChangesAsync();

        // 清空购物车
        _db.CartItems.RemoveRange(cartItems);
        await _db.SaveChangesAsync();

        await transaction.CommitAsync();
        return true;
    }
    catch
    {
        await transaction.RollbackAsync();
        return false;
    }
}

一个订单在事务里同时完成三件事：插入主表、插入明细、清空购物车。注意这里的 Traversal 是依赖 EF Core 的变更追踪，同一个 DbContext 实例才能保证这些操作在同一个事务里。如果购物车里的菜在用户下单前被商家下架了，那我就在创建订单前先检查菜品状态，如果有下架菜品直接返回提示。这一点踩过坑，后面问题排查部分会细说。

4.3 订单状态机和并发防重

订单状态机是整个系统的业务核心，我把它做成了一个服务类，把“允许的状态变更”集中在里面管理，而不是让各个 Controller 自己去判断，这样能避免很多逻辑不一致的问题。

csharp复制public static class OrderStatusMachine
{
    private static readonly Dictionary<OrderStatus, List<OrderStatus>> AllowedTransitions =
        new()
        {
            [OrderStatus.PendingPayment] = new() { OrderStatus.Cancelled, OrderStatus.PendingAccept },
            [OrderStatus.PendingAccept] = new() { OrderStatus.Making, OrderStatus.Cancelled },
            [OrderStatus.Making] = new() { OrderStatus.ReadyForPickup },
            [OrderStatus.ReadyForPickup] = new() { OrderStatus.Completed }
        };

    public static bool CanTransition(OrderStatus current, OrderStatus target)
    {
        return AllowedTransitions.ContainsKey(current) &&
               AllowedTransitions[current].Contains(target);
    }
}

把状态变更收敛到一个静态类里后，每个 Controller 要做的事情就只剩“校验角色 + 调用状态机 + 更新数据库”。比如接单操作，逻辑就是：先确认订单状态是待接单，再调用状态机判断是否能变更为制作中，能则更新。这样即使以后新增状态，也不会漏掉某个入口的校验。

另外一个容易踩坑的是用户双击提交订单。用户手一抖点了两次提交按钮，就会生成两笔一模一样的订单。解决方式有两个：一是前端在点击下单按钮后立即禁用按钮；二是后端做防重校验——在下单接口入口处检查用户是否在一分钟内有相同金额的待支付订单，如果有则直接返回原订单，不再新建。这两个措施我建议都上，前端防的是大多数用户手滑，后端防的是 API 层的恶意重放。

5. 前端页面开发与交互优化

5.1 页面布局与组件复用

我用的是 Bootstrap 5 免费模板做页面框架，因为点餐系统最需要的是把菜品图片和价格清晰展示出来，Bootstrap 的卡片组件天然适合做这个。

前台点餐页面分三个区域：顶部是导航栏（包含用户信息和购物车入口），左侧是菜品分类侧边栏，中间是菜品网格。菜品卡片上展示图片、名称、价格和一个“加入购物车”按钮。这里我踩了个小坑——Bootstrap 的栅格系统一行默认 12 列，我一开始为了让菜品卡片一行显示 4 个，直接写死了 col-lg-3 col-md-4 col-sm-6，但没考虑卡片高度不一致导致的排版错位问题。后来统一给卡片设置 min-height，同时把图片的高度固定为 200px 加 object-fit: cover，排版立刻整齐了。

后台管理页面其实比前台还重要，因为商家每天要在这个页面里完成接单、出餐、改菜品的操作。我的后台布局是左侧菜单、右侧内容区的经典结构，菜单按商家和管理员的角色动态渲染。做这块的时候我深刻体会到，后台管理系统最核心的设计原则是“减少操作步骤”——比如接单操作，列表页直接放一个“接单”按钮，点击后 AJAX 请求然后刷新当前行的状态，而不是跳转到详情页再点按钮。多一次跳转，商家一天就要多花很多时间。

5.2 用 fetch 调用后端 API 实现局部刷新

虽然整体是服务端渲染，但遇到“加入购物车”“接单”“取消订单”这类高频交互，我还是用 fetch 走 API 局部刷新。这样做的好处是页面不会白屏闪烁，交互响应更快。

前端代码大致是这样：

javascript复制async function addToCart(dishId) {
    try {
        const response = await fetch('/api/cart/add', {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'RequestVerificationToken': getAntiForgeryToken()
            },
            body: JSON.stringify({ dishId: dishId, quantity: 1 })
        });

        if (!response.ok) {
            const error = await response.json();
            alert(error.message);
            return;
        }

        const result = await response.json();
        updateCartBadge(result.cartCount);
        showToast('已加入购物车');
    } catch (ex) {
        console.error(ex);
        alert('网络异常，请稍后重试');
    }
}

这里有个安全细节是 RequestVerificationToken——ASP.NET Core 默认开启了防跨站请求伪造（CSRF）保护，凡是 POST 请求的 fetch 都必须带上这个 token，否则后端会直接返回 400。这个 token 是 Razor 页面里通过 @Html.AntiForgeryToken() 生成的，前端提交时从 Cookie 和表单里取出来放进请求头。很多新手第一次写前端带 token 时都容易卡在这一步，我自己也花了半小时排查这个 400 错误。

5.3 加载态、空态与错误提示的处理

这些细节是一个项目从“能跑”到“好用”的关键。

最基础的是提交按钮的防重复点击。下单按钮在点击后立即改成“提交中…”，同时 disable 按钮；请求完成后再恢复。不要小看这个操作，它解决的不只是用户体验问题，还有服务端的重复订单问题。

然后是空态设计。购物车为空时，页面要展示一个空购物车的插画加“去点餐”按钮，而不是白花花一片。订单列表为空时，提示“还没有历史订单”。这些看起来很小，但对用户留存率的影响比我预想的大得多。

最后是错误提示。我给 fetch 封装了一层，统一处理代码里的异常分支，服务端返回的错误信息会经过 JSON 序列化后显示在页面上。由于 ASP.NET Core 的 ModelState 验证会自动把参数校验错误显示到视图，如果是 API 请求我会把 ModelState 里的第一条错误信息提取出来作为 JSON 返回：

csharp复制public IActionResult AddToCart([FromBody] AddCartRequest request)
{
    if (!ModelState.IsValid)
    {
        var msg = ModelState.Values.SelectMany(v => v.Errors)
                                   .Select(e => e.ErrorMessage)
                                   .FirstOrDefault();
        return BadRequest(new { message = msg });
    }
    // ...
}

6. 部署上线与运行期问题排查

6.1 发布到服务器与进程守护

开发调试在自己电脑上跑得好好的，一部署到服务器就各种问题，这是所有 Web 开发者的必经之路。我这个项目的部署环境是 Windows Server + IIS，虽然 ASP.NET Core 支持跨平台，但公司服务器刚好是 Windows 生态，而且 IIS 的图形化管理对运维友好，所以没有刻意上 Nginx + Linux 那套。

部署有几个关键步骤：

第一，发布时选择“文件夹”模式，运行时选择“框架依赖”，这样服务器上只需要装对应版本的 .NET Hosting Bundle 就行，不需要把整个运行时打包进发布目录。当然，如果你不想在服务器上装任何运行时，可以选“自包含”发布，目录会大一些，但更省事。

第二，发布完把文件拷贝到服务器的物理目录后，要在 IIS 里新建网站，物理路径指向这个目录，应用程序池选“无托管代码”，绑定好心仪的端口。注意 ASP.NET Core 的 web.config 里会自动配置 aspNetCore 处理程序，不用手动写。

第三，最容易被忽略的是IIS 应用程序池的“闲置超时”设置，默认 20 分钟没有请求就会回收工作进程，导致第一次访问会特别慢（重新启动需要加载程序集和初始化数据库连接池）。我把闲置超时改为 0（永不回收），同时启用了“启动模式”里的 AlwaysRunning。

xml复制<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
  </handlers>
  <aspNetCore processPath="dotnet"
              arguments=".\OrderSystem.dll"
              stdoutLogEnabled="true"
              stdoutLogFile=".\logs\stdout"
              hostingModel="inprocess" />
</system.webServer>

hostingModel="inprocess" 这里我特意保留了，这是 ASP.NET Core 默认的托管方式，性能更好。如果遇到 IIS 进程崩溃的问题，可以临时改为 outofprocess 做对比。

6.2 上线后必须排查的两个经典问题

部署完成后，我做的第一件事不是宣布上线，而是用真实的账号走了一遍完整的流程。结果还真发现问题了。

一个问题是路径大小写敏感。本地开发时 URL 用的是驼峰命名，比如 /Order/Detail/1，在 Linux 上服务端路由本身不区分大小写，但同目录下的静态图片文件是区分大小写的。如果菜品图片文件名是 dish1001.JPG，访问时写成 /images/dish1001.jpg 在 Windows 上没事，在 Linux 上就会 404。我后来做了一个统一约定：所有图片文件名一律小写，从代码层面避免这个坑。

另一个问题是数据库连接超时。上线第一个星期，每天早上 9 点用户集中下单时，偶尔会有两三单失败，日志里报“Timeout expired”。原因很简单：默认的连接池最大连接数是 100，而早餐高峰时段同时请求的人多，加上每个请求要查购物车、查菜品、查库存，一个页面可能占 3-5 个连接，一下子就打满了。我做了两件事：一是检查有没有连接没释放的代码，查了一圈发现有一个列表页 Serilog 日志记录数据库操作时用了同步调用阻塞线程，改用异步日志后连接占用明显下降；二是在数据库连接串上调整了连接池参数：

code复制Server=localhost;Database=OrderSystem;User Id=sa;Password=***;Max Pool Size=200;Connect Timeout=30;

把连接池从默认的 100 调到 200，并清掉日志里同步的数据库操作，之后再没出现过这个错误。

6.3 安全加固：加密、校验与日志

这个项目虽然只是内部系统，但安全基线不能丢。我做了三方面的加固。

第一是敏感信息加密。用户密码使用 ASP.NET Core 自带的 PasswordHasher，它实现了 PBKDF2 算法，每次生成的哈希都带随机盐，直接存库。不要用 MD5、不要用 SHA1、不要自己拼盐，直接用框架提供的，这是最稳妥的。数据库连接串里的密码我放到了 appsettings.Production.json 中，并设置这个文件在部署时从发布目录里排除，由运维单独维护。

第二是请求校验防篡改。前面提到的 RequestVerificationToken 是防 CSRF 的标配；除此以外，凡是前端传来的订单号、金额这类参数，后端一律不直接信任，而要从服务端重新查数据库获取。比如用户提交支付金额时，不应该接受前端传来的 TotalAmount 值，而是根据购物车里的菜品价格重新计算。这个设计细节非常关键，防止用户篡改请求体重构价格。

第三是统一异常处理与日志。开发时要看详细错误，生产环境绝不能把堆栈信息返回给用户。我在中间件管道里加了全局异常处理：

csharp复制app.UseExceptionHandler(options =>
{
    options.Run(async context =>
    {
        context.Response.StatusCode = 500;
        var exception = context.Features.Get<IExceptionHandlerFeature>()?.Error;
        _logger.LogError(exception, "Unhandled exception: {Message}", exception?.Message);
        await context.Response.WriteAsJsonAsync(new { message = "服务器开小差了，请稍后重试" });
    });
});

这样用户收到的是友好的提示，技术人员可以从日志中定位真正的异常。日志我用了 Serilog 写文件，按天分割，保留 30 天，排错时非常管用。

7. 常见问题速查：我在实战中遇到的坑

7.1 问题汇总表

做整个项目下来遇到过的比较有代表性的问题，整理成一个速查表，方便你对照排查：

7.2 问题排查的一般思路

遇到线上问题，我个人的排查习惯是：

先看日志。Serilog 的文件日志里记录了所有请求的响应时间、错误堆栈和请求路径，能定位大多数问题的方向。

再复现问题。如果日志看不出名堂，就自己在测试环境复现一遍，用 F12 打开浏览器的 Network 面板，比较正常请求和异常请求的差异。

最后隔离环境。如果本地复现不了，就检查测试环境和生产环境的差异——版本号、数据库 schema、配置文件、服务器时区，都是常见嫌疑对象。

7.3 印象最深的两个问题复盘

第一个印象深刻的问题是商家端并行接单导致的状态覆盖。两个商家同时打开后台页面，看到同一张订单都是“待接受”状态，然后同时点击“接单”，后端接口都用“当前状态 == 待接受”作为前置条件做校验，结果两个请求都通过了校验，但后一个提交会覆盖前一个。最后订单状态变成“制作中”，但日志里有一个“待接受 → 制作中”的成功更新记录和一个“待接受 → 待接受”的失败记录（更新行数为 0）。修法是用乐观并发控制，给订单表加一个 RowVersion 字段，更新时带上旧的版本号做比对：

sql复制update Orders set Status = @newStatus, RowVersion = newid()
where Id = @orderId and Status = @oldStatus

EF Core 里可以用 IsRowVersion() 配置这个字段，更新时如果受影响行数为 0，就说明状态已被别人改过，直接返回“操作冲突，请刷新页面重试”。这个修复非常有效，也让我真切体会到并发的威力。

第二个是下单后菜品被别人下架导致的幽灵订单。用户把一道菜加入购物车，但一直没下单；过了一小时，商家把这道菜下架了（Dish.IsAvailable = false）；用户此时提交订单，后端虽然能从数据库查到菜品，但没有校验上架状态，结果生成了一笔包含已下架菜品的订单，商家端在备餐时完全不知道这道菜是什么味道。修复很简单，在创建订单的事务里，把每道菜的 IsAvailable 一并校验一遍，失败则提示“您购买的菜品已下架，请调整购物车”。这个问题的教训是：写业务逻辑时一定要考虑时间窗口，数据没有变，但数据的“状态”可能已经变了。

最后再说几句

项目做到这里，功能稳定、部署上线、问题排查完毕，感觉才算真正“落地”了。说实话，这个点餐系统从技术难度上看不算高深，但它让我把 ASP.NET Core 的认证授权、EF Core 的模型映射、事务处理、IIS 部署这一整套链路完完整整走了一遍，这些经验是看多少文档都学不来的。

如果非要说我印象最深的一件事，那就是在设计阶段多花的时间，最后都会百倍还给你。我当时要是没做状态机定义，后面在商家端、管理端不停地堆 if else，早就改崩溃了；要是不把表结构一次性设计好，中途加字段连带改七八个文件，估计最后两周都在干重复劳动。

这个项目做完以后，我又给它加了两个小功能：一个是按菜品销量排行生成周报表，另一个是给商家开放了简单的“今日概览”页面——今天接了多少单、营收多少、最受欢迎的菜是哪道。改动的体积不大，但内部的数据流转都复用现成的服务和查询方法，这让我觉得当初的分层设计是留对了余量。

如果这个实战经历对你有点帮助，那我建议你拿着这篇文章的思路，自己动手搭建一套——框架版本可以换，功能可以再发挥，但千万别改掉“状态机 + 三层结构 + 乐观锁”这几个骨干支撑。踩坑才能长本事，动手写永远比看教程快一步。