linkedin v1 api 对括号 `(` 和 `)` 的 url 编码（如 `%28`/`%29`）不兼容，会导致 404 和 `invalid.property.name` 错误；go 标准库 `http.newrequest` 会自动编码 url，可通过手动设置 `r.url.opaque` 绕过编码，保留原始路径结构。
在使用 Go 调用 LinkedIn v1 REST API（如获取用户基本信息）时，一个常见却易被忽视的问题是：API 路径中包含的圆括号 ( 和 ) 必须以字面形式存在，不可被 URL 编码。例如：
/v1/people/~:(id,first-name,last-name)
若交由 Go 标准库 net/url 自动解析（如 http.NewRequest("GET", url, nil)），它会将 ( 和 ) 分别编码为 %28 和 %29，导致最终请求路径变为：
/v1/people/~:%28id,first-name,last-name%29
而 LinkedIn v1 后端无法识别该编码形式，直接返回 404 及明确错误信息：
[invalid.property.name] . Couldn't find property with name {:%28id,first-name,last-name%29} in resource of type {Person}
⚠️ 注意：这不是认证或权限问题，而是路径解析层面的语义断裂——LinkedIn 的旧版 API 将 ~:(...) 视为特殊语法糖（类似字段投影表达式），要求括号保持未编码的原始字节。
✅ 正确解法：绕过自动编码，手动控制 URL 路径
Go 的 *http.Request 内部持有 *url.URL 实例，其 Opaque 字段用于指定“已编码且不应再处理的路径部分”。根据 net/url 文档：
Opaque is the encoded opaque data. It is used for non-absolute URLs.
因此，我们应构造一个基础 URL（仅含 scheme + host），再将完整、未编码的路径赋值给 r.URL.Opaque：
// ✅ 正确：避免括号被编码
r, err := http.NewRequest("GET", "https://api.linkedin.com", nil)
if err != nil {
log.Fatal("failed to create request:", err)
}
r.URL.Opaque = "/v1/people/~:(id,first-name,last-name)" // ← 关键：显式设置原始路径
r.Header.Set("Authorization", "Bearer "+respBody.AccessToken)
r.Header.Set("x-li-format", "json") // 推荐：显式声明 JSON 响应格式
resp, err := http.DefaultClient.Do(r)
if err != nil {
log.Fatal("request failed:", err)
}
defer resp.Body.Close()? 为什么有效？
- http.NewRequest("GET", "https://api.linkedin.com", nil) 创建的 r.URL 其 Path 为空，Opaque 为空字符串；
- 赋值 r.URL.Opaque = "/v1/people/~:(id,first-name,last-name)" 后，r.URL.String() 将直接拼接 Scheme + Host + Opaque，跳过所有 Path 相关的转义逻辑；
- 最终发出的 HTTP 请求行（如 GET /v1/people/~:(id,first-name,last-name) HTTP/1.1）完全符合 LinkedIn v1 的预期。
⚠️ 注意事项与最佳实践
- 仅适用于 LinkedIn v1（已弃用）：LinkedIn 自 2019 年起全面迁移到 Marketing Developer Platform (v2)，新 API 使用标准 REST 风格（如 /me?projection=(id,firstName,lastName)），且支持常规 URL 编码。本文方案不适用于 v2。
- 不要滥用 Opaque：该技巧仅用于绕过特定服务对特殊字符的非标准解析逻辑；对绝大多数现代 API（包括 GitHub、Stripe、Slack 等），应信任标准库的编码行为。
- 务必设置 x-li-format: json：LinkedIn v1 默认返回 XML，显式声明可避免解析失败。
- 错误处理不可省略：示例中省略了 err 检查仅为简洁；生产代码必须校验 http.NewRequest 和 Do() 的返回错误。
✅ 总结
当第三方 API（尤其是老旧系统）对 URL 编码有非常规要求时，Go 提供了底层可控机制——通过 URL.Opaque 直接注入原始路径，规避标准编码流程。这既无需修改标准库，也无需引入第三方 HTTP 客户端，是符合 Go 设计哲学的轻量级解决方案。但请始终优先查阅目标 API 的最新文档：LinkedIn v1 已停用，迁移至 v2 是长期必选项。
