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 将 ~:(...) 视为特殊语法糖（类似字段投影表达式），要求括号保持未编码的原始字节。
酷纬企业网站管理系统Kuwebs是酷纬信息开发的为企业网站提供解决方案而开发的营销型网站系统。在线留言模块、常见问题模块、友情链接模块。前台采用DIV+CSS，遵循SEO标准。 1.支持中文、英文两种版本，后台可以在不同的环境下编辑中英文。 3.程序和界面分离，提供通用的PHP标准语法字段供前台调用，可以为不同的页面设置不同的风格。 5.支持google地图生成、自定义标题、自定义关键词、自定义描
✅ 正确解法：绕过自动编码，手动控制 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 是长期必选项。
