国内这种几乎只能单向接收信息了，这不是互联网，这是数字广播

那我这种工作两年了的，还有希望吗
@pluvet

不差这点流量，现阶段人类可读比这点流量重要得多

@tuchg Unicode 很复杂，很容易出现看上去一样但比较字符就是不一样的情况，容易出事

主要是切输入法有点烦，不过真要是不好翻译，就用全拼吧，这种地方非 ASCII 兼容字符尽量不要用，Unicode 太复杂，容易出问题

最新版，关闭 Spring/JakartaEE 相关的全部插件

只单纯去关注歧视，讨论某个过程中的机会均等就会陷入这种状况，只有去关注分配，关注最终的平等才能从彻底上解决这些问题。

某种意义上确实是个高效的筛选方式，你看，迅速筛选掉了一大部分人，被人质疑时还会有人为自己说话。
只是很多事情大家目前还无法从心理上接受抽签而已

没事，Go 的标准库就当没有就行，大道至简嘛~~~

各放各的 controller ，不要被路由左右了，你看 ktor 那种写法，你就不会纠结这些有的没的了

你要是不担心被发现后的背调履历问题，试试也无妨，他搞歧视你就搞造假，你来我往才有意思

如果选用第二种的话考虑下要么每个 post 的 comments 都有独立的序列（比如楼层号），要么考虑下两者冲突时怎么弄；第三种的话，那就是个 id 了，没法在那个地方放楼层号了；

一开始 bing 是好用的，自从某个时间点后它动不动就不理你了…

上班第一天开全盘加密，离职时重置，密钥没了应该读不到有用的东西了吧

@xlbychen97 不完全的确认允许提交吗？如果允许，你关心这个干嘛；如果不允许，这一个确认标示代表所有确认不好么

不知道具体业务，只能根据自己理解的说说自己的想法，触发拦截和提示时报错返回，确认时增加一个额外的确认指示，看到确认指示则忽略提示

包括 DLNA 大部分都要在本地解码（服务端可能会提前做一次转码），解码后的视频流体积很大，对带宽时延都有要求，网络难搞

var 主要是有点弱，只能在局部变量用，但是我觉得不该不许用。lombok 这东西还是别用了，你一用所有人都得跟着用，而且还不是个第一方的东西，不太好

另外每个请求都传输主密码是非常不安全的行为