Npgsql Remove、Clear 后连接串仍残留 Encoding

调用 Remove("Encoding") 后，连接串没有少一个键，反而出现 Encoding=UTF8；调用 Clear()，Count 也可能仍是 1。若代码依靠“已删除”来生成新的配置，先检查最终序列化结果，而不只是方法是否正常返回。

这里的具体键是 Encoding 和 Kerberos Service Name。它们具有非空字符串默认值。Npgsql 10.0.3 构建器删除路径会恢复默认属性值，而属性 setter 又把默认值写回键集合。给索引器赋 NULL 仍会进入 Remove，不能作为另一种可靠的删除方式。

默认生效与键不存在是两件事

不显式提供 Encoding 时，驱动本来就可能使用 UTF8。删除这个键的需求，通常是配置合并、连接串规范化或下游策略要求，而不是想让驱动“不使用任何编码”。同样，移除 Kerberos 服务名不会自动停用 Kerberos，也不会修复认证权限。

先确认自己的真实需求。如果只是希望恢复默认行为，显式默认值可能已经符合要求；如果必须从输出连接串中移除键，就需要检查实际 Keys 与序列化内容。不要把完整连接串打印到日志，它可能含密码和认证材料。

用普通构建器处理这一步过滤

已确认遭遇该行为时，可以先用普通 DbConnectionStringBuilder 解析驱动生成的规范连接串，定向删除键，再创建新的 Npgsql 构建器验证其余设置：

using System.Data.Common;
using Npgsql;

var raw = new DbConnectionStringBuilder
{
    ConnectionString = existingBuilder.ConnectionString
};
raw.Remove("Encoding");
raw.Remove("Kerberos Service Name");

var result = new NpgsqlConnectionStringBuilder(raw.ConnectionString);

existingBuilder 是应用已有的 NpgsqlConnectionStringBuilder。示例沿用其规范键名，避免在任意原始输入里猜别名。之后核对 result 的序列化键确实符合预期，并比较 Host、数据库、TLS、超时和其他认证设置；不要为了移除两个键改成自己按分号切字符串，那会误伤带引号或转义的值。

若需要一份真正的空配置，使用新的构建器并按受控模板填入所需字段，而不是在旧对象上反复 Clear。空配置不能直接替代一份已经可用的生产连接串，重建时必须明确保留必要的连接与安全约束。

这类问题不需要连接数据库就能定位。先在应用测试中验证两个键分别存在、同时存在、原本不存在以及 Clear 后的结果，再验证过滤后的配置仍能由驱动接受。实际连通性和身份校验沿用项目原来的有界检查，不能用“字符串成功生成”替代连接验收。

保留原配置的安全恢复副本；若新版本调整了删除实现，再复核是否还需要这一层过滤。它只处理键集合行为，不应扩展成关闭 TLS、修改认证方式或清空连接池的理由。