为何将RequestUri作为参数传入与在HttpRequestMessage中设置表现不同

两种写法的表现差异核心源于Uri实例的创建规则和请求处理的逻辑分工：

• 第一种写法调用的是HttpRequestMessage(HttpMethod, string)重载，传入的相对路径字符串会被内部自动创建为UriKind.Relative类型的Uri实例，拼接逻辑由HttpClient在发送请求阶段执行，会自动将该相对Uri和自身配置的BaseAddress拼接为完整的绝对Uri，因此可以正常运行。
• 第二种写法报错的根源是调用了无参数配置的Uri构造函数new Uri(string)，这个构造函数默认要求传入的字符串是绝对Uri，传入的相对路径不符合要求因此抛出格式错误。

如果要手动给RequestUri属性赋值相对路径，不需要手动拼接BaseAddress字符串，只需要在创建Uri时显式指定类型为相对Uri即可，效果和第一种构造函数传参完全一致：

RequestUri = new Uri($"account-lookup/?query={email}", UriKind.Relative)

• 不推荐直接用字符串拼接BaseAddress + 相对路径的方式创建Uri，这种写法很容易出现斜杠不匹配的问题（比如BaseAddress末尾没有斜杠、相对路径开头有斜杠的场景下，拼接后的路径会丢失BaseAddress的最后一段）。更稳妥的方式是使用Uri的重载构造函数自动处理拼接：new Uri(Client.BaseAddress, $"account-lookup/?query={email}")，这个重载会自动处理斜杠、转义等规则，避免手动拼接的错误。
• RequestUri属性设计为Uri类型而非字符串，是.NET的类型安全设计，目的是强制开发者明确区分相对Uri和绝对Uri，避免隐式转换带来的未知错误。

内容的提问来源于stack exchange，提问作者M Kenyon II