Blazor中子组件@ref的适用场景及两种组件控制方式对比

问题1：OnAfterRender中设置VisibilityComponent2初始状态的实现是否正确？ #

这个实现可以达到最终效果，但存在明显缺陷，不属于正确的实践：

1. 存在冗余渲染：bool类型字段默认值为false，组件首次渲染时VisibilityComponent2内部的showComponent是false，会先以隐藏状态渲染一次；等OnAfterRender触发后调用SetVisibility把状态改成true，又会触发子组件第二次重渲染，平白多了一次渲染开销，组件内容复杂时甚至可能出现可见状态闪烁。
2. 存在性能隐患：你当前的OnAfterRender方法没有加firstRender判断，父组件每完成一次渲染，都会重复调用SetVisibility方法，哪怕visibilityState的值没有任何变化，会反复触发子组件重渲染。
3. 状态同步逻辑脆弱：后续如果新增其他修改visibilityState的逻辑，很容易遗漏调用SetVisibility方法，直接导致父子组件状态不一致。

问题2：两种实现方式的核心区别与适用场景 #

两种方式的核心差异是状态所有权归属和数据流模式完全不同，适用场景有明确边界：

• 方式1（Parameter参数传值）：采用Blazor标准的单向数据流模式，可见性状态的所有权完全归属于父组件，子组件只做纯渲染接收方，不持有内部状态。父组件状态变更时，Blazor会自动把新参数值传给子组件、触发子组件重渲染，不需要任何手动调用逻辑。
• 方式2（@ref调用公开方法）：属于命令式跨组件操作，可见性状态的所有权在子组件内部，父组件不直接持有状态，只能通过获取子组件实例、调用公开方法的方式间接修改子组件状态，状态同步、渲染触发都需要开发手动写代码维护。

Parameter传值方式的适用时机 #

这是Blazor开发的首选默认方案，覆盖90%以上的常规业务场景：

• 当组件的展示状态、传入数据完全由父组件决定时，都应该用这种方式。比如控制组件显隐、传入列表展示数据、设置表单禁用状态、配置组件样式参数等场景。
• 优势是状态流清晰可追溯，所有状态统一在父组件维护，不会出现父子状态不同步的问题，也不需要写额外的生命周期同步代码，维护成本低、bug率低。

你当前的组件显隐切换需求，最佳实现就是两个组件统一采用Parameter传值，不需要@ref、不需要OnAfterRender逻辑，父组件只需要维护一个状态变量即可，优化后的代码如下：

@page "/"    

<button @onclick="ToggleVisibility">Toggle Visibility</button>
<br />
<VisibilityComponent1 ShowComponent="visibilityState"></VisibilityComponent1>
<br />
<VisibilityComponent2 ShowComponent="visibilityState"></VisibilityComponent2>

@code
{
    private bool visibilityState = true;

    private void ToggleVisibility()
    {
        visibilityState = !visibilityState;
    }
}

VisibilityComponent2只需要把原来的私有字段和SetVisibility方法删掉，和VisibilityComponent1一样声明[Parameter] public bool ShowComponent { get; set; }即可。

@ref命令式调用方式的适用时机 #

这种方式仅适合触发子组件内部封装的、不涉及跨组件状态同步的内置行为，绝对不要用来做常规的属性/状态传递：

• 典型适用场景：调用子组件封装的输入框聚焦方法、触发子组件内部的重置表单逻辑、调用第三方UI组件封装好的弹窗打开/关闭、动画播放/暂停、图表重绘等内置方法。
• 简单判断标准：如果你发现自己需要在生命周期方法里给子组件同步初始状态、或者每次修改父组件变量都要手动调子组件方法同步值，就说明这个场景不适合用@ref，应该把对应状态提成组件参数走单向数据流。

内容的提问来源于stack exchange，提问作者sukesh