C#中List.Add未新增元素反而替换，UDP接收代码异常排查

核心分析 #

你遇到的现象违背了List<T>.Add的基本行为——正常情况下Add仅会追加元素，不会替换现有内容。结合你提到“在线C#编译器运行正常”，问题大概率出在调试环境的显示误差或运行时的变量作用域冲突，而非代码逻辑本身。

可能原因与验证步骤 #

• 调试器视图未实时刷新
  调试器有时会因缓存、多线程调度（即便用同步Receive，UDP底层仍可能有线程交互）导致变量视图未能实时更新。不要仅依赖断点的调试面板，直接在循环内添加打印语句验证实际状态：

  received.Add(strBuffer);
  // 添加打印代码确认实际状态
  Console.WriteLine($"当前列表元素数：{received.Count}");
  foreach(var item in received)
  {
      Console.WriteLine($"元素内容：{item}");
  }
  Console.WriteLine();
  

  运行后查看控制台输出，确认列表是否真的只保留了最后一个元素。

• 变量作用域冲突
  检查类库代码中是否存在与局部变量received同名的类级别字段。虽然局部变量会优先作用，但不排除代码重构疏漏等特殊场景下，你实际操作的是类字段而非局部列表。可以给局部变量重命名（比如改为receivedDatagrams），再测试是否复现问题。

• Socket接收的潜在疏漏（非当前问题直接原因，但建议修复）
  你当前忽略了Socket.Receive的返回值——该值表示实际接收的字节数。直接将整个65535字节的缓冲区转成Base64，会包含大量填充的0（转成Base64的'A'），即便用TrimEnd('A')处理，也可能导致数据截断不准确。正确的做法是只转换实际接收的字节：

  int bytesReceived = client.Receive(buffer);
  string strBuffer = Convert.ToBase64String(buffer, 0, bytesReceived);
  // 此时无需再TrimEnd('A')，因为仅转换了有效数据
  

总结 #

优先通过控制台打印确认列表的实际状态，排除调试器显示问题；其次排查变量作用域冲突；最后修复Socket接收的代码疏漏。由于在线编译器运行正常，代码逻辑本身没有致命问题，问题大概率出在运行环境或调试环节。

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