KiraMaple

我测试了下，如果还能登录 ChatGPT 网页就能添加 codex 令牌，然后用令牌访问即可。如果连登录 ChatGPT 网页都需要验证手机号，那就没办法了

@huanxianghao 但是今天试了下 gemini 3.5 flash ，貌似真挺好的，虽然综合能力赶不上 A/和 openai 家的，但这个是 flash ，下个月的 pro 不知道啥情况，估计也不赖

直接用 vscode 啊，vscode 里面很多 git 相关的插件，我基本上常年使用 vscode 连接远程 linux 机器写代码，git 插件就 vscode 自带的 git 功能+gitlens+git graph ，不用付费都可以

现阶段如无必要(看你的条件，那其实就不是必要)，不要买房，公寓、住宅都不要。房价上升阶段的时候，贴四个钱包买房都是不亏的，即使是自住房，后面条件好了更换住房，原方子也能很好出售，也卖得出价格，这个是把房子当投资品角度来思考。房价下降阶段，基本就是当消费品来思考，花全副家当买个消费品，就和你现在花 130w 买个车差不多的逻辑。买完可能就亏几万十几万，后面每年都亏点钱，房子只是现在可能没车子跌那么夸张，以后保不齐。所以看看买 130w 车的都是啥样的人，你到那个层级再考虑以消费品的逻辑去买 130w 的房。
看你后面补充的，你问 130w 买成都户口有没有必要？现在房价下行阶段就是越晚买越合适，当你真的不得不买的时候，直接买住宅，上成都户口，现在房子绑定的也就这个价值了(而且这些政策也在逐步松动)，而公寓是连这点价值都没有的垃圾。你现在买住宅是多 130w 买成都户口，可能晚几年等要结婚生子的时候买，那可能成都户口都大放水了。

@jeesk #65 那可能我的知识过时了，我接触 grpc 的时候都是好多年前，后面也没有长期使用，当时确实是需要浏览器有 HTTP2 支持

@chaleaochexist gRPC 中的 RPC ，Remote procedure call 翻译作远程过程调用，RPC 概念的提出初衷就是期望像调用本地接口一样远程调用其他服务上的接口。protobuf 作为一个序列化工具，为了支持 gRPC 也支持定义服务和服务中的接口，用来生成调用方的代理调用接口。最开始 gRPC 使用回调的方式达到本地调用的编码体验，但这样容易陷入回调地狱。后来某些编程语言中退出了类似 await/async 等机制，才解决了回调地狱。这样的体验和调用本地接口的编码体验几乎无异，除了你知道这是异步和需要 await 关键字。
HTTP 经过封装也是可以达到效果的，说到底，gRPC 是基于 HTTP2 结合了 protobuf 、通信、RPC 等功能的一个更上层的 SDK ，如果你是期望达到 RPC 的编码体验，既然有 gRPC 珠玉在前，何必自己用裸 HTTP 再造轮子。

@jeesk #40 gRPC 基于 HTTP2 ，不是所有浏览器都完全支持 HTTP2 的，虽然现在绝大互联网产品都是基于较新的浏览器设计了，但是一些政企部分的客户端系统可能会很老。在更早时候，这个情况更严重，所以 gRPC 在早年更适合服务器之间通信，现在也就形成了路径依赖。

我个人认为 gRPC 的着重点是 RPC 上，可以在微服务/CS 之间像调用本地函数一样调用其他服务的函数，这能极大提升开发效率，但也需要通信的双方协议对齐，这是 RPC 的特点。因为 gRPC 最终打包接口采用的 protobuf ，一个非常优秀的序列化反序列化方案，这能带来更低的流量和更好的性能。也因为采用了 protobuf ，让浏览器上开发调试的时候变得更加复杂，比如 xml/json 那么清晰。不过 protobuf 带来的好处其实 i 也可以依托其他高效的序列化方案来处理。不过 gRPC 很多特性是依托较新浏览器特性才能支持的，所以它对浏览器的支持有一定要求。
相反在微服务之间的场景几乎没有上述所说的诸多缺点，所以现阶段 gRPC 更多还是用在微服务之间的调用或者 BS 模型的产品。