转成 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

来来来，细说 3 倍效率怎么计算出来的！为什么是 3 而不是 100 ？写 100 会不会更吸引人？

贴个经常要处理的 python 问题。

TypeError: unsupported operand type(s) for -: 'int' and 'NoneType'

不是针对 python ，只是刚好又要修个这种 bug 。js 也是一样，经常有 undefined 问题。

写代码的时候，脑袋里还要记忆某个属性存在不存在是真 tm 的累。然后，这种 NoneType Error 、undefined 问题还是数据相关的，可能你开发的时候压根不会碰到。

@ChrisFreeMan 我认为底层库的最低要求是，声明好接口的参数与返回值类型，保证用的人能清晰的知道怎么调用即可。至于实现部分，如果掌握不住体操，那就 any 吧。

还有，凡事多先自己体会下，技术圈有点娱乐化了，尤其是前端。这种现象感觉也开始蔓延到后端。天天要用新技术重写一个世界。最近感觉吐槽 Go 的文章开始多起来了，然后开始吹 Rust 。估计再过个一两年，今天的小甜甜，也要变成牛夫人。

你管他大佬不大佬，大佬还能帮你写 CRUD ，还能帮你写基础建设吗？大佬，也会犯错误。

写写小脚本、小应用，倾向于不用。

但是，项目一大，你怎么知道 item 、data 、form 等等这些对象有什么属性？靠 JS + VSCode 是不靠谱的，补全不精准，重命名也是个大硬伤，动不动把很古老的文件里的同名属性也给我改了，这怎么能忍？

经常看到有人吐槽 AnyScript 。说到底要嘛学得不深，要嘛由钻研得太深。该用 any 、as 、!的时候，你就大胆的使用。然后尽量不要类型转换超过 3 次，这种类型体操做起来累，看起来也是很累！ TS 已经是可以渐进式的使用了，别一上来自缚手脚，搞个火箭发射台。