看到 2 楼喷 session+cookie 我就想笑。

Web 场景下，你 jwt 放哪里？不还是得放在 http-only + secure 的 cookie 里？

什么？你不放 cookie 里，你要放在 localStorage 里？注入的 js 攻击分分钟偷走你的宝贝 jwt 。

@musi 这玩意没办法给你完全解决。你说，API 请求到的对象，就是不安约定的来一定要少个字段，这种无解。 但是其它大部分情况，都能在 build 时报错提醒你某某字段可能是 nil ，你需要处理好。

另外，纠正一下，溢出的是 JS Runtime ，不是 JSON 。在你把一个 int64 转成 JSON 格式的时候，它并没有“失真”，可以在其它支持 int64 的语言里试试。

之前看 Twitter 的前端代码的时候，偶然发现他们有 `id_str` 这样的字段，今天翻了下文档，果然是为了处理大数溢出问题。https://developer.twitter.com/en/docs/twitter-api/v1/data-dictionary/object-model/tweet

js 这个“缺陷”的原因我知道。

话说，js 未来是否能支持真正的 int 类型，面量就写成 类似 `97i32` 或者 `97i`之类的？

@jazzg62 请问下，如果这个数字要回传给后端你们怎么处理？也是让后端在 server 拿到后转成数字吗？

@coala 同意。不过遗留项目，已成定局。

@mxT52CRuqR6o5 可以呀。

问题是，不是所有的 bigint 转成 string 都能相安无事。

比如，如果这个数字是用来做 ID 之类的，那它是 string 也无所谓，因为很少会对 ID 做什么加减乘除的运算。

但是这个 bigint 可能是表示毫秒、表示钱，这时候转成 string 就很不方便。而且后端又不是只为 js 服务，还有 ios 跟 android 。

转成 string 给前端，前端送回给后端的时候，后端得再转回 int （ python 后端），现在其实就是这么做的。就是时不时会遗漏掉，而且这种问题是要等溢出你才会发现。基于此，想寻找一个更好的方案。

@realJamespond 就是不想再在后端转字符串了呀！

除非从 DB Access 层就把所有 bigint 都转成 string ，顺便好奇问下大家也是这么做的吗？像 timestamp 这种，在 db 里用 bigint 存储，但是使用的时候是实实在在要当数字使用的，如果转成 string 用的时候还要转回去。

@z1645444 感谢，这个多少能满足了我的需求。Pycharm 貌似没有专门 extend selection 到整个函数或者 class 的接口，不知道是不是我搜索得不对，不过直接用 extend selection 也够用。

我用的不是纯 vim ，主要在 pycharm 里使用。纯 vim 偶尔在 server 的 cli 里使用。这些 plugin 貌似用不了。

@javaisthebest 哈哈~~ 太真实。 让我想起了 DELETE /user/session/123123123 。 说到底，rest 还是不适合复杂情景。

感谢分享。

我感觉独立开发者，做这种项目，更多的是打磨给别人写外包的脚手架。面向的用户是开发者自己就行了，什么拖拽编辑等等需求都不太强烈。

https 保证通讯安全。jwt 只是保证认证的格式，你用自己生成的随机数都可以，只不过它带有一些基础信息，可以省去向中心服务验证的过程。

客户端拿到 token 后，要自己存在一个安全的地方。
- 像浏览器场景，基本都要存在 http-only 的 cookie 里。这个 http-only 表示只有浏览器能读取，js 无法读取。跟 http/https 没关系。这样能保证攻击注入的 js 无法读出你的 token 。
- app 场景，应该是直接存 app 本地就好，别的 app 读取不到，没写过 app 不知道这方面的安全规范。
- server 2 server 场景，你拿到 token 后就自己存好，方式各种各样。大部分情况下，因为这个 server 只有你能访问，所以直接明文“随意”存个位置也是可以的。

你辛辛苦苦把 token 保存得很好，但是对外传输的时候竟然用了明文的 http ，那别人就特别容易截到你的 token ，来伪造你的请求。比如，把你网上银行的钱转走。。。

@NerbraskaGuy antd 那种适用于后台系统我知道。toC 场景下，这种“样式没法复用很正常”真的是常态吗？ T_T