大家好，我是码农刚子。这是「Radzen 实战」第 1 篇，复盘 SPcbERP 里那些差点出事的真实坑。
SPcbERP 是 PCB 行业 ERP，前端用 Radzen.Blazor 搭。项目跑了小半年，一直稳。
上个月做依赖升级，把 Radzen.Blazor 从 5.x 升到 6.0.0。编译一次过，dotnet run 正常，浏览器一打开——白屏。
控制台报一串看不懂的错。来回折腾两天才理清，一共四个坑，一个比一个隐蔽。
今天全写出来，你升级的时候照着对一遍，能省两天。
01 坑一：NU1107，依赖版本打架
这个坑最直接，编译就报，不会等到运行。
报错原文：
NU1107: Version conflict detected for Microsoft.AspNetCore.Components.Web. Reference the package directly from the project to resolve this issue. SPcbERP -> Radzen.Blazor 6.0.0 -> Components.Web (>= 8.0.10) SPcbERP -> Components.Web (>= 7.0.0)翻译一下：Radzen.Blazor 6.0.0 要 Components.Web 8.0.10 以上，你项目里直接引了 7.0.0，两边对不上。
麻烦的是，.NET 8 项目里 Components.Web 本来是框架隐式提供的，正常根本不用手写版本。但一旦你因为某个功能手动引了一次，版本就被钉死了，升级 Radzen 时就会撞。
SPcbERP / \ Radzen.Blazor 6.0.0 Components.Web （传递依赖） （项目里手动引用） | | 要求 >= 8.0.10 要求 >= 7.0.0 \ / ⚡ NU1107 版本冲突三个办法，按省事程度排：
一、删掉手动引用。如果那个直接引用不是必需的，删掉，让 Radzen 的传递依赖决定版本。最干净。
二、显式对齐版本。在 csproj 里把 Components.Web 显式指到 8.0.10 以上，和 Radzen 的要求一致。
三、锁 Radzen 版本。暂时升不上去就先别升，等依赖链理顺再说。
顺序提醒：先解决 NU1107，再谈其他坑。编译不过，后面的错根本看不到。
02 坑二：DataGrid 分页，Count 得自己赋值
编译过了，页面能开了，但表格分页不对。
RadzenDataGrid 做服务端分页，用LoadData事件。6.0 里这个事件的参数类型是DataGridLoadDataEventArgs，里面有Skip和Top，但没有 Count。
总条数得你自己查出来，赋给args.Count。不赋值，分页器不知道一共多少条，只能显示一页。
只查数据，忘了 Count：
async Task LoadData(DataGridLoadDataEventArgs args) { args.Data = await db.Orders .OrderBy(o => o.Id) .Skip(args.Skip).Take(args.Top) .ToListAsync(); // args.Count 没赋值 → 分页器算不出总页数 }数据 + 总数一起给：
async Task LoadData(DataGridLoadDataEventArgs args) { var query = db.Orders.AsQueryable(); // 总数单独查一次 args.Count = await query.CountAsync(); args.Data = await query .OrderBy(o => o.Id) .Skip(args.Skip).Take(args.Top) .ToListAsync(); }代价是多一次COUNT查询。但这是服务端分页绕不开的成本——分页器要知道总页数，就得知道总数。除非你关掉分页器，改用「上一页/下一页」的游标式导航。
顺带一提：
LoadData在筛选、排序变化时也会触发。你的 Count 查询必须和 Data 查询用同一套筛选条件，否则筛选后页数还是按全表算的，会出现「筛出来 3 条，却有 5 页」。
03 坑三：DialogService 的泛型和默认尺寸
第三个坑是弹窗。表现有两种：要么弹不出来，要么弹出来窄得像手机屏。
6.0 里DialogService.OpenAsync的泛型推断更严格了，DialogOptions的Width/Height不显式指定的话，默认值和 5.x 不一样。
靠默认值撑满：
await DialogService.OpenAsync<EditOrder>( "编辑订单", new Dictionary<string, object> { { "Id", id } }); // 6.0 里默认宽度变了，弹窗变得很窄尺寸和泛型都写死：
await DialogService.OpenAsync<EditOrder>( "编辑订单", new Dictionary<string, object> { { "Id", id } }, new DialogOptions { Width = "800px", Height = "600px", Resizable = true });还有一个相关的：Close()的传参。如果你的弹窗要返回值，OpenAsync<T>的T是返回类型，Close(null)在 6.0 里会因为推断不出类型而编译失败。老老实实写Close(default(T))或者干脆改成Close(false)这种能推断出类型的值。
经验：凡是「靠默认值生效」的地方，升级时都要重新显式声明一遍。默认值是库的内部决定，它改了不会通知你。
04 坑四：样式类名变了，自定义 CSS 全失效
这个坑最难查，因为它不报错。
页面看着「没坏」，但变丑了——表格边框没了、按钮圆角没了、对话框标题栏变白。
原因是 6.0 调整了组件生成的 DOM 结构和 CSS 类名。你项目里针对老类名写的覆盖样式，一条都不生效了。
我的建议是：别去覆盖 Radzen 的具体类名，用它的主题 CSS 变量。类名是内部实现，换个版本就可能变；CSS 变量才是对外承诺的接口。
排查方法也很土但有效：升级后拿浏览器 DevTools 对着一个表格、一个按钮、一个弹窗，逐个对比 DOM 和计算样式。半小时能捞干净。
05 升级 Radzen 的避坑清单
| 时机 | 动作 |
|---|---|
| 升级前 | 翻一遍 release notes 里的 breaking changes，别只看版本号 |
| 升级前 | 先看依赖树，把 NU1107 这类冲突提前排掉 |
| 升级后 | 服务端分页的表格，逐个确认 Count 有回填 |
| 升级后 | 弹窗全部显式指定 Width/Height 和泛型参数 |
| 升级后 | 过一遍视觉回归，重点看表格、按钮、对话框 |
| 长期 | 锁死包版本，别用浮动版本号，升级当成一次小项目做 |
四个坑里，NU1107 是硬错误，编译就拦你；剩下三个都是软错误——不报错，只是行为变了。软错误才最耗时间，因为你得先意识到「它变了」。
一句话总结：升级组件库，别只看版本号。依赖冲突先排掉，靠默认值的地方全部显式写一遍，升完做一次视觉回归。
你在 Radzen 或者别的组件库上栽过最贵的坑是啥？评论区唠唠。
转发给正在做依赖升级的同事，少走我们趟过的弯路。
下一篇聊：SaveChanges 一万行？换批量操作快 10 倍。
关于作者
码农刚子，六年 ERP / 制造业系统开发，专注 C# / .NET / Blazor。
博客原文：Radzen 6.0.0 这几个 API 坑，我替你踩了 - 码录集
