Go 怎样生成无填充 URL 令牌

Go 生成无填充 URL 令牌，可以先用 crypto/rand 生成随机字节，再调用 base64.RawURLEncoding.EncodeToString。它采用字母、数字、短横线和下划线，不带结尾的等号。随机字节决定不可预测性，Base64 只决定文本表示，两件事不能混为一谈。

我会把这项调整看成协议格式选择，而不是某次升级才出现的新能力。对需要放进 URL 的不透明令牌，我倾向于直接约定 base64url 无填充形式；如果对接方已经明确要求带填充，则不会单方面修改输出。这里没有加密，也不会把用户编号编码一下就变成秘密令牌。

Go 官方地址：https://go.dev/
编码文档：https://pkg.go.dev/encoding/base64

我会把改变限定在令牌的编码形式

标准 Base64 与 URL 安全 Base64 的区别不只有等号：标准字母表含 + 和 /，URL 安全版本用 - 与 _ 替代它们。“Raw”表示省略填充，不表示原始明文，也不表示无需解析。

因此我更愿意在生成端直接选择 RawURLEncoding，而不是先生成标准 Base64，再到处替换字符、删除后缀。编码器和解码器保持一致，调用方才知道该接受哪一种格式。RFC 4648 把这种字母表称为 base64url，并区分是否采用填充的协议约定。RFC 4648 的 URL 安全编码说明

随机性来自字节，不来自那串字符

本例选 32 字节随机数据，对应 256 个二进制位；无填充编码后得到 43 个 ASCII 字符。这是长度换算，不是额外增加了随机性，也不是“绝不会重复”的保证。应用仍应根据用途、有效期和请求规模制定令牌策略。

crypto/rand 提供密码学安全随机来源。不要用时间戳、自增编号或普通随机数替代它，更不要在生成失败时悄悄退回这些来源。当前 Go 文档说明 rand.Read 会完整填充切片且不返回普通错误；示例保留错误处理以兼容旧版接口用法，不声称它能恢复当前运行时的不可恢复故障。crypto/rand.Read 文档

生成和格式检查各写一个函数

下面是可独立保存为 main.go 的示例。newToken 只生成；parseToken 只接受本例约定的规范文本。程序最终只输出长度，不打印生成的令牌。

package main

import (
    "crypto/rand"
    "encoding/base64"
    "errors"
    "fmt"
    "log"
)

const tokenBytes = 32 // 这是本例的协议选择，不是所有业务的固定标准。
var tokenEncoding = base64.RawURLEncoding.Strict()

func newToken() (string, error) {
    raw := make([]byte, tokenBytes)
    // 保留错误分支以兼容旧版Go；不要用弱随机源兜底。
    if _, err := rand.Read(raw); err != nil {
        return "", fmt.Errorf("生成随机令牌: %w", err)
    }
    return tokenEncoding.EncodeToString(raw), nil
}

// parseToken 只检查格式，不判断账户、用途、有效期或是否已使用。
func parseToken(s string) ([]byte, error) {
    if len(s) != tokenEncoding.EncodedLen(tokenBytes) {
        return nil, errors.New("令牌长度不符")
    }
    for i := 0; i = 'A' && c = 'a' && c = '0' && c 

这里先限定长度与字符，再严格解码，并通过重新编码检查规范表示。原因是 Strict 主要约束尾部未使用的位，标准库解码仍会忽略换行；不能把 Strict 理解为自动拒绝所有形式的非规范输入。本例显式字符检查还会拒绝空白、等号、加号和斜线。Strict 的适用范围

对我来说，这种明确的格式契约比“能解码就都收下”更容易维护，但也有代价：它会拒绝旧格式。parseToken 成功只说明输入符合 32 字节令牌的编码形状；任何人都能构造同样形状的字符串，所以它不是授权通过的证明。

旧令牌切换时我不直接删等号

如果原系统只是使用 URLEncoding 的带填充形式，切换也需要同步修改接收方；如果原来是 StdEncoding，仅删除等号连字母表差异都没处理。我的迁移取舍是给格式一个明确版本或入口，在有限兼容期内分别解码，并给新签发记录标记格式，而不是对任意输入循环尝试所有编码器。

已经发行的令牌还可能被服务端按原字符串保存或计算摘要。修改文本表示会改变查找键，不能只在 URL 中删掉字符而不考虑存储。格式迁移与令牌失效策略应一起设计；本文不实现数据库兼容层。

放进链接以后还要守住哪些约定

即使字母表适合 URL，我仍会用 net/url 构建查询参数。下面是业务函数内部的片段，需要导入 net/url、fmt、errors；base 来自可信配置，不能直接拿未经确认的请求 Host 拼接账户操作链接。

// token 为生成函数的返回值，base 来自可信的服务配置。
u, err := url.Parse(base)
if err != nil {
    return "", fmt.Errorf("解析服务地址: %w", err)
}
if u.Scheme != "https" || u.Host == "" || u.User != nil {
    return "", errors.New("服务地址不符合链接约定")
}
q := u.Query()
q.Set("token", token) // 交给URL组件编码，不手动拼接问号和连接符。
u.RawQuery = q.Encode()
return u.String(), nil

仅检查 scheme 与 Host 非空不等于域名白名单，可信来源仍由应用配置保证。对于密码重置等用途，OWASP 建议使用 HTTPS、可信域名构建链接，并防止 Referer 泄露与暴力猜测；令牌还需安全存储、关联用户、到期及使用后失效。这些是完整业务的要求，不是编码函数已实现的功能。OWASP URL 令牌建议

我不会把完整令牌或带令牌的 URL 当成普通调试字段。它可能出现在代理访问日志、浏览器历史与页面跳转中；缩短文本和去掉等号都无法消除这些暴露面。存储侧可根据协议保存随机令牌摘要，并将用途、有效期和使用状态与记录绑定；并发消费时需要原子地完成有效性判断与状态更新。

怎样判断结果符合自己的协议

把完整程序保存后，读者可在练习目录运行下面命令；本文未运行代码，也不展示真实秘密令牌或伪造测试日志。

# 在新的练习目录初始化模块，已有模块可跳过此行。
go mod init example.com/url-token-demo
# 程序只显示长度，不将令牌正文写到终端。
go run .

按本例约定，应输出“字符数=43，原始字节数=32”。读者还可以分别检查是否含 =、+、/ 或空白，确认生成值能解码回 32 字节。不要把“运行几次没有重复”当作随机源安全性的证明。

无填充就无法还原吗？可以还原，但接收方必须使用匹配的无填充解码约定；这不是加密。不要把私密业务字段直接编码后当作隐藏数据。

能统一转成小写吗？不能。Base64 字母表区分大小写，转换会改变表示甚至数据。复制、存储和传递时保持完整原文。

能直接当 JWT 吗？不能。一个无填充 Base64url 随机串只是这里的不透明令牌；它没有 JWT 的结构、签名和声明语义。选择协议时先明确需要随机查表令牌还是具备验证规则的其他凭证。

我的结论很具体：需要简洁、固定格式的 URL 随机令牌时，crypto/rand 加 RawURLEncoding 足够表达生成职责；真正赋予它权限的，是服务端记录和消费规则。把两层分开，格式变更才不会被误当成安全能力升级。