您老是不是用 WiFi 开浏览器在那测速着呢？插网线再测，200 打我谢谢

你想多了，12306 本来就是一个随机分配系统，票是随意分配到多个节点的，抢票也是随意落到某个节点，对全局没有任何影响，主要突出一个机缘

A 股有简单模式有困难模式

你要是梭在茅台上其实问题不大，怕就怕自作聪明梭在野鸡股上

@nomagick jwt 中不是 session token 讲错了是 session id ，jwt 是明文的，不能直接给 token ，要用 jwt 的签名

我现在的处理办法是 jwt 中放置 session token ，想验哪个验哪个，正常情况下两个都验，遇到外部系统验证不了 session 就只验证 jwt 签名

功能越多就越抽象，整体性越强，门槛越高。
编程这个行当仍在不断发展，越能与时俱进，就越不稳定。

你想降低门槛，那么就会破坏整体性，一些功能就会被滥用。
你想稳定，那么就会破坏可拓展性，生命周期就会短。

你大部分语法和 js 一致，建议你看一下 coffee script ，看它是如何走上和走下历史舞台。

签名没问题，但关心 body 的格式和内容就过分了，谁设计的，不胜任，并且已经影响了商誉

你税真交全了吗

自己高兴就好。。。

启动快 5 倍，那不加载代码可不就快了吗，跟 vite 似的，启动是快了，访问的时候等着

@robinshen 关系很大，但不是直接关系，生态吸收不到人才，已有的人才流出，新的语言概念得不到应用，架构得不到换代，这些都会间接作用在项目质量上，而且是无解的。

微软花多少成本在维护 GH ，GL 又花了多少成本维护，而你一个人就已经把项目做到了这个程度，这就是云泥之别。

所谓云原生完全就是炒作概念，换句话说，云原生就代表离开云就运行不了，那岂有此理。首先需要重新定义云，把云替换解释成 k8s ，这样才可控，否则就为他人做嫁衣了，很多人做了半天都是给 AWS 在做销售。只要做到 k8s 全兼容就可以称云原生了，和语言无关。

一个坐吃山空的人管他作甚。。。

咱们一般的开发者还是要冷暖自知，小马过河的故事听过没有

他能坐吃山空，一般人有那个山可供坐吃吗

我又多想了几步，你这个项目的竞品 GitLab, 什么 Gitee ，再就是 GitHub Enterprise ，这几位有个特点就是都是 Ruby 项目。

我现在家里装个 GitLab 隔三差五就是 email 说安全漏洞让我 update-asap ，这五年多就从来没断过，也不知道他哪来那么多安全漏洞，修也修不好，敢情他家漏洞比隔壁 PHP 那边的难兄难弟还多几倍。

Ruby 现在江河日下，跟不上时代，还不如 C++上进，马上就要步 Perl 的后尘。
只需要推波助澜，替天行道，加速 Ruby 进入历史的垃圾堆。

有些事长痛不如短痛，一个语言跟不上时代之后，人才就会持续流出，因为学习它的收益很低，并且落后于行业，由于人员的流出，这个语言的项目就更难得到发展，而维护难度和费用却不断增长，最终进入价高质低陷阱。
之前 Cobol 和 Perl 的淘汰都已经展示了这套运行机制，需要吸取教训。

所以说在进行市场活动的时候，可以指出竟品维护的可持续性及成本的问题，提醒甲方不要花钱买个大爷。
另外借上 Java 的东风，就说总之是个 Java 项目甲方自己也可以改，并且 Java 的从业人员简直不要太好找。

基于这些假设甚至可以主动出击，对 Ruby 釜底抽薪，比如找人发表一篇 九评 Ruby ，
再比如对其他 Ruby 的遗产项目比如 HomeBrew 进行打击，用 Python 重写 brew ，甚至借助 GPT4 的力量直接把整个生态平移。这个项目本身体量小但影响大，四两拨千斤。

这种打法我愿称之为降维打击

我觉得你的这个方案很适合需要私有 GitLab 类似物，但是不愿意运行 Ruby 的情况。
Ruby 什么时候死，你的项目就什么时候起飞。
这件事迟早要发生，坚持住，提前做好布局，到时候就是你的主场。

插件的问题，语言模型管不了那么多

@OPLUS 我记得 temperature 不一样，可以检查一下，temperature 太高了之后幻觉大于记忆， 比较直观的是低 temperature 的时候出师表背得挺好，调高之后就胡言乱语。
包括线上的 130b 版本背出师表也是胡言乱语，但是本地 6b 低 temperature 就背得挺好。