前端atob解码JWT触发编码错误，现有修复方案是否符合最佳实践？

问题背景 #

前端开发中需要校验本地存储的JWT是否过期，最初实现的校验函数如下：

tokenExpired(token: string) {
    const expiry = JSON.parse(window.atob(token.split('.')[1])).exp;
    return Math.floor(new Date().getTime() / 1000) >= expiry;
  }

调用时对入参做了兜底，jwtToken不存在时传入空字符串：

if (!this.tokenExpired(this.jwtToken || '')) {
      this.getAccountData().subscribe(
        (data) => {
          this.accout = data;
          this.isLoggedIn();
        },
        (err) => {
          this.isLoggedIn$.next(2);
        }
      );
    } else {
      this.isLoggedIn$.next(2);
    }

代码构建上线后控制台抛出错误：Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.
待确认两个问题：

• 除atob/window.atob外，有哪些可用的JWT解码替代方案
• 后续新增空值判断后的修复代码不再抛错，该方案是否符合良好开发实践

新增空值判断后的修复代码如下：

tokenExpired(token: string) {
    if (token !== '') {
      const expiry = JSON.parse(atob(token.split('.')[1])).exp;
      return Math.floor(new Date().getTime() / 1000) >= expiry;
    } else {
      return false;
    }
  }

具体解答 #

可用的atob替代解码方案 #

首先要明确：atob报错的核心诱因不止空入参。JWT默认使用URL安全的Base64URL编码，会把标准Base64中的+替换为-、/替换为_，且通常不会补全编码末尾要求的=填充字符，直接传入atob就很容易触发编码格式错误，空字符串只是触发报错的场景之一。
常见的可行替代方案有三类：

• 原生兼容预处理方案：不需要引入额外依赖，先把JWT的Payload部分从Base64URL转为标准Base64格式，补全填充位后再交给atob解码，额外加编码兼容处理避免非ASCII字符乱码：

function decodeJwtPayload(token: string) {
  const base64UrlSeg = token.split('.')[1];
  // 转标准base64
  const base64Seg = base64UrlSeg.replace(/-/g, '+').replace(/_/g, '/');
  // 补全=填充位
  const padLen = 4 - (base64Seg.length % 4);
  const paddedSeg = padLen !== 4 ? base64Seg + '='.repeat(padLen) : base64Seg;
  // 解码+兼容非ASCII字符
  return JSON.parse(decodeURIComponent(escape(window.atob(paddedSeg))));
}

• 现代Web API实现：使用标准TextDecoderAPI配合类型化数组解码，兼容所有现代浏览器，避开atob对编码格式的严格校验问题：

function decodeJwtPayloadModern(token: string) {
  const base64UrlSeg = token.split('.')[1];
  const base64Seg = base64UrlSeg.replace(/-/g, '+').replace(/_/g, '/');
  const padLen = 4 - (base64Seg.length % 4);
  const paddedSeg = padLen !== 4 ? base64Seg + '='.repeat(padLen) : base64Seg;
  const binStr = atob(paddedSeg);
  const bytes = Uint8Array.from(binStr, char => char.charCodeAt(0));
  return JSON.parse(new TextDecoder().decode(bytes));
}

• 生产环境推荐方案：直接使用轻量的专门JWT解码库，这类库已经处理了所有编码兼容、边界异常、类型适配问题，不需要自己维护解码逻辑，gzip后体积不到1KB，不会带来额外的包体积负担。

现有空值判断方案的实践评估 #

你当前加了空字符串判断的代码仅解决了空入参触发的报错，不属于完善的良好开发实践，存在三个明确问题：

1. 逻辑语义错误：当token为空时，函数返回false，也就是判定「token未过期」，会继续发起getAccountData请求，但空token本质就是未登录的无效状态，应该直接判定为过期/无效，走未登录分支才符合逻辑，当前返回值写反了。
2. 缺少异常兜底：即使token非空，也可能存在格式被篡改、不符合JWT三段式结构、payload没有exp字段、编码非法等情况，这些场景下split、atob、JSON.parse任一步骤都会抛出未捕获异常，导致页面运行错误。
3. 没有处理Base64URL和标准Base64的格式差异，遇到携带-/_字符、未补全=填充位的合法JWT，依然会触发atob的编码报错。

可以参考优化后的生产可用校验逻辑：

tokenExpired(token: string): boolean {
  // 空值、不符合三段式JWT结构直接判定为无效/过期
  if (!token || token.split('.').length !== 3) return true;
  try {
    const payload = decodeJwtPayload(token);
    // 没有exp过期字段的JWT按无效处理
    if (typeof payload.exp !== 'number') return true;
    return Math.floor(Date.now() / 1000) >= payload.exp;
  } catch (err) {
    // 所有解码、解析异常都判定为token无效
    return true;
  }
}

内容的提问来源于stack exchange，提问作者devZ