ASP.NET Core 试题 40：SignalR 实时通信
0781 在 Hub 生命周期 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 一个连接始终绑定同一个 Hub 实例直到断开
- B. 需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存
- C. SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态
- D. 观察到“第二次调用读取不到第一次写入的 Hub 字段”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 Hub 生命周期 的主规则：SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态。选项“需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存”是使用规则时要验证的边界，不是规则本身；“一个连接始终绑定同一个 Hub 实例直到断开”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0782 第二次调用读取不到第一次写入的 Hub 字段。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“一个连接始终绑定同一个 Hub 实例直到断开”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存”。
- C. 以一次成功请求作为结论，不再确认“SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态”是否成立。
- D. 先验证“需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存”，再依据“SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“第二次调用读取不到第一次写入的 Hub 字段”指向 Hub 生命周期，但症状本身不能证明根因。正确排查应先确认边界“需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存”，再用主规则“SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态”解释证据。直接采用误区“一个连接始终绑定同一个 Hub 实例直到断开”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0783 关于 Hub 生命周期，以下哪项说法不成立？
难度： 实战
- A. 一个连接始终绑定同一个 Hub 实例直到断开
- B. SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态
- C. 需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存
- D. 出现“第二次调用读取不到第一次写入的 Hub 字段”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“一个连接始终绑定同一个 Hub 实例直到断开”正是 Hub 生命周期 的典型误区。其余三项分别给出了主规则“SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态”、适用边界“需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0784 针对“第二次调用读取不到第一次写入的 Hub 字段”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“一个连接始终绑定同一个 Hub 实例直到断开”修改实现，并把一次请求成功作为验收结果。
- B. 按“SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态”修正实现，并用测试或遥测验证“需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存”。
- C. 按“SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态”修改代码后直接上线，不验证“需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存”。
- D. 只验证“需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存”，但实现仍继续依赖“一个连接始终绑定同一个 Hub 实例直到断开”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：SignalR Hub 实例是短暂的，不应在实例字段保存跨调用状态；并确认 需要从应用其他服务发送消息时使用 IHubContext，持久状态存数据库或缓存。继续接受“一个连接始终绑定同一个 Hub 实例直到断开”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“第二次调用读取不到第一次写入的 Hub 字段”这一生产场景能否安全上线。
0785 在 Groups 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 加入组一次后用户永久属于该组且跨服务器重启保留
- B. 重新连接后需按授权重新加入组，组名本身不能作为权限证明
- C. 观察到“重连用户不再收到房间消息”即可把一次现象当成完整框架契约。
- D. 组用于向一组连接广播，组成员关系通常不是持久业务数据
查看答案与解析
正确答案D
正确答案直接描述 Groups 的主规则：组用于向一组连接广播，组成员关系通常不是持久业务数据。选项“重新连接后需按授权重新加入组，组名本身不能作为权限证明”是使用规则时要验证的边界，不是规则本身；“加入组一次后用户永久属于该组且跨服务器重启保留”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0786 重连用户不再收到房间消息。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“加入组一次后用户永久属于该组且跨服务器重启保留”定性，不再检查配置、身份或运行时证据。
- B. 先验证“重新连接后需按授权重新加入组，组名本身不能作为权限证明”，再依据“组用于向一组连接广播，组成员关系通常不是持久业务数据”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“重新连接后需按授权重新加入组，组名本身不能作为权限证明”。
- D. 以一次成功请求作为结论，不再确认“组用于向一组连接广播，组成员关系通常不是持久业务数据”是否成立。
查看答案与解析
正确答案B
场景“重连用户不再收到房间消息”指向 Groups，但症状本身不能证明根因。正确排查应先确认边界“重新连接后需按授权重新加入组，组名本身不能作为权限证明”，再用主规则“组用于向一组连接广播，组成员关系通常不是持久业务数据”解释证据。直接采用误区“加入组一次后用户永久属于该组且跨服务器重启保留”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0787 关于 Groups，以下哪项说法不成立？
难度： 实战
- A. 组用于向一组连接广播，组成员关系通常不是持久业务数据
- B. 重新连接后需按授权重新加入组，组名本身不能作为权限证明
- C. 加入组一次后用户永久属于该组且跨服务器重启保留
- D. 出现“重连用户不再收到房间消息”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“加入组一次后用户永久属于该组且跨服务器重启保留”正是 Groups 的典型误区。其余三项分别给出了主规则“组用于向一组连接广播，组成员关系通常不是持久业务数据”、适用边界“重新连接后需按授权重新加入组，组名本身不能作为权限证明”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0788 针对“重连用户不再收到房间消息”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“组用于向一组连接广播，组成员关系通常不是持久业务数据”修正实现，并用测试或遥测验证“重新连接后需按授权重新加入组，组名本身不能作为权限证明”。
- B. 按“加入组一次后用户永久属于该组且跨服务器重启保留”修改实现，并把一次请求成功作为验收结果。
- C. 按“组用于向一组连接广播，组成员关系通常不是持久业务数据”修改代码后直接上线，不验证“重新连接后需按授权重新加入组，组名本身不能作为权限证明”。
- D. 只验证“重新连接后需按授权重新加入组，组名本身不能作为权限证明”，但实现仍继续依赖“加入组一次后用户永久属于该组且跨服务器重启保留”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：组用于向一组连接广播，组成员关系通常不是持久业务数据；并确认 重新连接后需按授权重新加入组，组名本身不能作为权限证明。继续接受“加入组一次后用户永久属于该组且跨服务器重启保留”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“重连用户不再收到房间消息”这一生产场景能否安全上线。
0789 在 认证与连接 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异
- B. 连接建立时认证一次就保证未来所有权限永不变化
- C. 敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证
- D. 观察到“用户被封禁后现有连接仍可调用方法”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 认证与连接 的主规则：SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异。选项“敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证”是使用规则时要验证的边界，不是规则本身；“连接建立时认证一次就保证未来所有权限永不变化”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0790 用户被封禁后现有连接仍可调用方法。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“连接建立时认证一次就保证未来所有权限永不变化”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证”。
- C. 先验证“敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证”，再依据“SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异”是否成立。
查看答案与解析
正确答案C
场景“用户被封禁后现有连接仍可调用方法”指向 认证与连接，但症状本身不能证明根因。正确排查应先确认边界“敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证”，再用主规则“SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异”解释证据。直接采用误区“连接建立时认证一次就保证未来所有权限永不变化”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0791 关于 认证与连接，以下哪项说法不成立？
难度： 实战
- A. SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异
- B. 连接建立时认证一次就保证未来所有权限永不变化
- C. 敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证
- D. 出现“用户被封禁后现有连接仍可调用方法”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“连接建立时认证一次就保证未来所有权限永不变化”正是 认证与连接 的典型误区。其余三项分别给出了主规则“SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异”、适用边界“敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0792 针对“用户被封禁后现有连接仍可调用方法”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“连接建立时认证一次就保证未来所有权限永不变化”修改实现，并把一次请求成功作为验收结果。
- B. 按“SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异”修改代码后直接上线，不验证“敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证”。
- C. 只验证“敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证”，但实现仍继续依赖“连接建立时认证一次就保证未来所有权限永不变化”。
- D. 按“SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异”修正实现，并用测试或遥测验证“敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：SignalR 在建立连接时关联用户身份，长连接期间令牌过期处理因传输和配置而异；并确认 敏感操作仍应在 Hub 方法中授权，权限撤销可能需要主动断开或重新验证。继续接受“连接建立时认证一次就保证未来所有权限永不变化”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“用户被封禁后现有连接仍可调用方法”这一生产场景能否安全上线。
0793 在 横向扩展 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 只增加 Pod 数即可自动让所有节点广播到同一组
- B. 多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息
- C. 不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发
- D. 观察到“客户端分散到不同实例后互相收不到消息”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 横向扩展 的主规则：多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息。选项“不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发”是使用规则时要验证的边界，不是规则本身；“只增加 Pod 数即可自动让所有节点广播到同一组”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0794 客户端分散到不同实例后互相收不到消息。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发”，再依据“多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息”判断实现是否符合契约。
- B. 直接按“只增加 Pod 数即可自动让所有节点广播到同一组”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发”。
- D. 以一次成功请求作为结论，不再确认“多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息”是否成立。
查看答案与解析
正确答案A
场景“客户端分散到不同实例后互相收不到消息”指向 横向扩展，但症状本身不能证明根因。正确排查应先确认边界“不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发”，再用主规则“多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息”解释证据。直接采用误区“只增加 Pod 数即可自动让所有节点广播到同一组”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0795 关于 横向扩展，以下哪项说法不成立？
难度： 实战
- A. 多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息
- B. 不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发
- C. 出现“客户端分散到不同实例后互相收不到消息”时，应收集证据并同时核对主规则与适用边界。
- D. 只增加 Pod 数即可自动让所有节点广播到同一组
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“只增加 Pod 数即可自动让所有节点广播到同一组”正是 横向扩展 的典型误区。其余三项分别给出了主规则“多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息”、适用边界“不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0796 针对“客户端分散到不同实例后互相收不到消息”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“只增加 Pod 数即可自动让所有节点广播到同一组”修改实现，并把一次请求成功作为验收结果。
- B. 按“多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息”修改代码后直接上线，不验证“不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发”。
- C. 按“多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息”修正实现，并用测试或遥测验证“不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发”。
- D. 只验证“不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发”，但实现仍继续依赖“只增加 Pod 数即可自动让所有节点广播到同一组”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：多实例 SignalR 需要 Azure SignalR Service 或 Redis backplane 等协调跨节点消息；并确认 不同方案对粘性会话、传输和故障恢复要求不同，负载均衡不能只随机分发。继续接受“只增加 Pod 数即可自动让所有节点广播到同一组”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“客户端分散到不同实例后互相收不到消息”这一生产场景能否安全上线。
0797 在 流与消息大小 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 使用 MessagePack 后任何大对象都可零成本无限传输
- B. 流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存
- C. SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小
- D. 观察到“慢客户端导致服务器缓冲不断增长”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 流与消息大小 的主规则：SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小。选项“流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存”是使用规则时要验证的边界，不是规则本身；“使用 MessagePack 后任何大对象都可零成本无限传输”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0798 慢客户端导致服务器缓冲不断增长。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存”，再依据“SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小”判断实现是否符合契约。
- B. 直接按“使用 MessagePack 后任何大对象都可零成本无限传输”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存”。
- D. 以一次成功请求作为结论，不再确认“SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小”是否成立。
查看答案与解析
正确答案A
场景“慢客户端导致服务器缓冲不断增长”指向 流与消息大小，但症状本身不能证明根因。正确排查应先确认边界“流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存”，再用主规则“SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小”解释证据。直接采用误区“使用 MessagePack 后任何大对象都可零成本无限传输”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0799 关于 流与消息大小，以下哪项说法不成立？
难度： 实战
- A. SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小
- B. 使用 MessagePack 后任何大对象都可零成本无限传输
- C. 流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存
- D. 出现“慢客户端导致服务器缓冲不断增长”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“使用 MessagePack 后任何大对象都可零成本无限传输”正是 流与消息大小 的典型误区。其余三项分别给出了主规则“SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小”、适用边界“流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0800 针对“慢客户端导致服务器缓冲不断增长”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“使用 MessagePack 后任何大对象都可零成本无限传输”修改实现，并把一次请求成功作为验收结果。
- B. 按“SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小”修改代码后直接上线，不验证“流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存”。
- C. 只验证“流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存”，但实现仍继续依赖“使用 MessagePack 后任何大对象都可零成本无限传输”。
- D. 按“SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小”修正实现，并用测试或遥测验证“流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：SignalR 支持服务器到客户端和客户端到服务器流，并可配置最大消息大小；并确认 流必须观察取消和背压，不能允许无限消息或无界缓冲占满内存。继续接受“使用 MessagePack 后任何大对象都可零成本无限传输”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“慢客户端导致服务器缓冲不断增长”这一生产场景能否安全上线。