站第一种

这个功能目前在用 lazy.nvim 作者 folke 的 snacks.nvim

https://github.com/folke/snacks.nvim/blob/main/docs/gitbrowse.md

snacks 还能支持 visual 模式的多行 link 复制和直接在浏览器打开。

可以看看这个睡眠的科普视频。（字幕有英语，也可以自动翻译到中文）
https://youtu.be/fOsaVft0Mtw

有时候过不去可能是因为你复制的内容被标记为机密信息，比如你在 1password 里复制密码就都不会被同步。

用了很多年了，我记忆里接力没有怎么失败过，一直挺好用的。

技术文档的话片假名术语多属于正常现象

Rokcy Linux

按照使用频度来说
Discord > Slack > 微信 > Telegram = Line > QQ > iMessage

在海外还喜欢打游戏的话，Discord 基本是第一了。我自己同时也维护一些 discord 社区，日常算泡在 discord 上，机器人功能可以随便开发真的挺爽的。熟人间游戏直播也方便，有时候技术讨论也用，没有时间限制。

工作上的事情永远只用公司手机号，公司 Slack ，或者通过邮件交流，其他交流方式问就是没在用。
只要工作时候别给微信，家族群全部塞进折叠，个人感觉微信用起来还是挺丝滑的，偶尔打开朋友圈看看。
Line 作为日本微信，在日本生活肯定避不开的，多少得用。

虽然之前是直接看的 avante 源码配置的，现在发现官方也做了个 wiki ，没放在 readme 里而已。
https://github.com/yetone/avante.nvim/wiki/Custom-providers

avante 支持自定义的啊？
我最小化配置了下，没啥问题

```lua
{
"yetone/avante.nvim",
opts = {
provider = "deepseek_3",
auto_suggestions_provider = "deepseek_3",
vendors = {
deepseek_3 = {
__inherited_from = "openai",
endpoint = "https://api.deepseek.com",
model = "deepseek-chat",
api_key_name = "DEEPSEEK_API_KEY",
},
},
behaviour = {
auto_suggestions = true,
},
},
},
```

avante.nvim

相反，我微信绑的海外手机号，这 10 年来总是来回被冻结又解锁，经常钱都取不出来，慢慢的不敢用了。
最近又提示我要绑定国内手机号，现在已经连点都都不进去了。
支付宝就没这种问题，回国期间绑好身份信息就完全没限制了，各个国家都能用。

@andrew2558 不需要吧，用英语界面试试，海外也挺多用 deepseek 的

@FakerLeung

榜单上的话不说同水平，至少逼近是有的。
但这个实际效果还得自己去体感测试下，反正现在用 API 还是打折的，一百万 token 才两块钱，放到 cursor ，avante 里面高强度用个一周先看看效果。
也可以试试网页版的 V3 ，注册后是纯免费的。

nextjs 15 之前已经用上 19 rc 了，但是我目前接触到的前端项目，是没有人敢现在升级到 nextjs 15 的。

5 楼的感觉非常赞同，React 生态现在有种所有东西都要去兼容 Next （+Remix ）的风气，然而 Next 很多特性的推进过于激进，React 也有种唯 Vercel 马首是瞻的感觉，不同以往了。

写的话我自己是直接在 datagrip 里手写。
如果有连接到数据库会有类似于代码补全的智能提示。就算没有买 JB 全家桶授权，只要有 IDEA 系任一 IDE 都一样有数据库功能。不一定要 datagrip 单体版本

其他自己觉得不错的点
1. 我们组同时管理的数据库有大概 50 几个，datagrip 可以 mysql ，Cassandra ，trino 啥的全覆盖挺爽的。2. 能自定义各种前置脚本可以自动过不同生产环境和开发环境的堡垒机。包括证书登陆只要写个 jdbc 地址一样能过。
3. 会话不删除就一直在，可以达到一定的历史需求。
4. 当前 db 生成 sql 也挺常用。
5. 能直接把结果和编辑结合起来达到类似 Jupyter notebook 的效果。每一步的结果分开展示在开发时候非常方便。
6. 可视化操作的每一步都可以看到实际上执行了什么 SQL ，一边进行可视化操作还能一边确认命令或者复用命令

如果不 squash merge 的话，在 commit merge 强烈推荐 rebase 。

不过话说回来，除非 200 个 commit 都是独立的模块化改动，否则 200 多个 commit 加入主 branch 说实话意义不大。
就算事后出问题总不能单独 revert 其中一个 commit 吧，200 多个大部分 commit 估计修改部分都互相依存了。
结果上看还是要大规模批量 revert 然后修改后再重新 release ，对比来说 revert 一个 squash 的 commit 还便捷一点。
所以我个人习惯上尽量保持一个功能改动 squash merge 一次。如果很复杂的话拆成几个 PR ，还能降低 code review 的理解成本。

公司内部有不少，但是没有外网链接。体感 用 DI : 不用 DI = 7:3 的样子。

如果业务逻辑非常简单，依赖非常清晰，没有什么分岔的话，其实用不用 dig 写起来差不多的。个人经验来说依赖注入在 Go 大部分情况下都是伪需求或者说提升编码效率的小工具，开始的时候没用的话不必要强上。要跨组件公用的话，直接暴露一个变量或者一个 getter ，内部用 once 啥的初始化一下就行。

单元测试要补强的话，在写的时候就一定要习惯用 interface 来声明组件，方便之后 mock 。（当然另一个方面来说，Interface 写多了，用 DI 自动串起来还是挺方便的。）说实话每次写单元测试都感觉挺不 Go 的，还是 Java 那套思路。但是回头想想，非常多单元测试实际上没有任何作用，只是单纯提升 coverage 而已。现在我比较喜欢把核心逻辑去掉各种 side effect 抽到某个函数里，然后对函数做比较多的 UT ，其他 side effect 直接交给后面的 e2e 什么的来验证。还是要具体情况具体分析，避免无效工作。

工作上确实也有类似场景，用 jq 在 zsh 里写个简单的 function 其实就可以了