Blazor父子通信用Parameter和EventCallback；WASM调API需正确配置HttpClient并处理CORS；响应URL变化应使用NavigationManager.LocationChanged事件并注意反注册；WASM调试时局部变量可能不准确，建议用Console.WriteLine辅助。
Blazor组件间怎么传数据：父子通信最稳用 Parameter 和 EventCallback
父子组件通信不是靠全局状态，也不是靠 JS 互调，而是靠 Blazor 原生的属性绑定机制。父组件把数据当 Parameter 传给子组件，子组件想通知父组件就用 EventCallback 触发回调。
常见错误是直接在子组件里改父组件的字段（比如传了个 List<string></string> 进去然后 .Add()），结果 UI 不刷新——因为没触发重渲染，也没走 StateHasChanged()。正确做法是父组件自己改数据，再靠参数更新驱动子组件重绘。
- 父组件传值必须加
[Parameter]特性，否则子组件收不到 -
EventCallback<t></t>的泛型类型要和InvokeAsync()实际传的参数一致，不然运行时报System.InvalidOperationException - 避免传引用类型（如
Dictionary<string object></string>）后在子组件里直接修改，应该用新对象替换整个参数，或让父组件暴露修改方法
Blazor WebAssembly 怎么调后端 API：别漏掉 HttpClient 配置和跨域处理
WebAssembly 模式下，HttpClient 默认复用浏览器的 fetch，所以 CORS 是硬门槛。本地开发时后端没配 Access-Control-Allow-Origin，就会卡在 Failed to fetch 或 net::ERR_FAILED，控制台还可能不报具体错误。
容易被忽略的是 HttpClient 实例生命周期。在 Program.cs 里用 builder.Services.AddScoped<httpclient>()</httpclient> 是错的——WASM 不支持 Scoped 生命周期，得用 AddSingleton 或更稳妥的 AddHttpClient（它内部管理连接池和超时）。
- 开发阶段后端若为 ASP.NET Core，确保
Startup.cs或Program.cs中有app.UseCors()且策略允许前端地址（如https://localhost:5001） - 调用接口前检查
response.IsSuccessStatusCode，不要只靠 try-catch，401/404 等 HTTP 错误不会抛异常 - WASM 启动慢，首次请求延迟高，别在
OnInitializedAsync里塞多个串行 API 调用，考虑用Task.WhenAll并行，但注意后端限流
Blazor 组件怎么响应 URL 变化：用 NavigationManager 监听路由，别手动解析 LocationChanged
想让组件感知地址栏变化（比如从 /user/123 切到 /user/456），不能靠监听 window.location 或轮询 Uri，得用 Blazor 内置的 NavigationManager。它提供 LocationChanged 事件，但要注意注册和反注册时机，否则内存泄漏。
典型坑是把 NavigationManager.LocationChanged += HandleLocationChange 写在 OnInitialized 里，却不写 Dispose 解绑，组件销毁后事件还在，下次导航会重复触发。
- 必须在
Dispose(bool)或实现IAsyncDisposable时调用NavigationManager.LocationChanged -= HandleLocationChange -
LocationChanged事件参数里的args.Location是完整 URL，解析路径要用NavigationManager.ToBaseRelativePath()，避免硬切字符串 - 如果只是想读当前路由参数，优先用
@page "/user/{Id:int}"+[Parameter] public int Id { get; set; }，比手动监听更可靠、更符合框架设计
WebAssembly 模式下怎么调试 C# 代码：断点能打，但别信“局部变量”面板
VS 或 VS Code 里按 F9 打断点基本可用，但 WebAssembly 的调试体验和服务器端差一截。最大问题是局部变量面板常显示 <optimized out></optimized> 或值不更新，尤其在异步方法、LINQ 链式调用或内联函数里。
根本原因是 Mono WebAssembly 运行时做了 JIT 优化，且调试符号映射不全。这时候别死磕变量窗口，改用 Console.WriteLine 或 Debug.WriteLine 输出关键值，输出内容能在浏览器 DevTools 的 Console 标签看到。
- 发布模式（
dotnet publish -c Release）默认关闭调试信息，调试务必用-c Debug - Chrome 浏览器需启用
chrome://flags/#enable-webassembly-exception-catching才能捕获未处理异常 - WASM 加载慢，首次断点可能卡在
Program.cs第一行，等几秒再点“继续”，否则容易误判为卡死
Blazor WebAssembly 的通信链路比服务端渲染多一层 WASM 运行时和浏览器沙箱约束，很多“本该工作”的事，其实卡在 CORS、调试符号、生命周期或参数传递方式上。这些地方不显眼，但改错一个就能省两小时。
