localstorage 是纯客户端 api，无法通过服务端代码直接写入，服务器只能借助响应内容向浏览器发送 javascript 脚本，在页面加载时由浏览器执行并写入 localstorage。
localStorage 是浏览器提供的 Web Storage API 的一部分，其生命周期和作用域完全限定在客户端（即用户浏览器中），由 JavaScript 运行时环境（如 V8、SpiderMonkey）管理。与 Cookie 不同，它不参与 HTTP 请求/响应流程：服务器无法通过响应头（如 Set-Cookie）或任何内置函数（如 Go 的 http.SetCookie）直接操作 localStorage —— 因为它根本不存在于服务端上下文，也不暴露给 HTTP 协议。
✅ 正确实现方式：服务端「注入」可执行的前端逻辑
你可以在服务端渲染 HTML 响应时，将初始化数据嵌入
func handler(w http.ResponseWriter, r *http.Request) {
data := map[string]string{
"userId": "12345",
"theme": "dark",
}
// 序列化为 JSON 字符串（注意转义，防止 XSS）
jsonData, _ := json.Marshal(data)
tmpl := `
Init localStorage
`
fmt.Fprintf(w, tmpl, string(jsonData))
}⚠️ 注意事项：
- 安全性优先：务必对嵌入的 JSON 数据进行严格转义（如使用 html.EscapeString 或模板引擎的自动转义功能），避免脚本注入（XSS）；推荐使用 html/template 而非 text/template，并调用 .EscapeJS 方法。
- 时机限制：该方式仅适用于服务端渲染（SSR）场景；若为纯 API 服务（如返回 JSON 的 REST 接口），则必须由前端 JS 主动发起请求后自行调用 localStorage.setItem()。
- 替代方案考量：若需服务端强管控持久化状态，应优先考虑 Cookie（带 HttpOnly/Secure 标志）、服务端 Session，或结合 JWT + 客户端存储的混合方案。
总结：localStorage 的设计哲学是“客户端自治”，服务端无法绕过浏览器安全模型直接写入。所谓“服务端设置 localStorage”，本质是服务端生成并交付一段可信的客户端执行逻辑 —— 这不是后端能力的延伸，而是前后端协作的约定模式。
