有没有性价，要看你个人需求。

对我来说是省心不折腾：统一的 unix 环境　> 命令行(一键操作、自动化) > 全局 readline 快捷键 > 触摸板(十年没再用鼠标) >　续航。

我很多年前折腾各类 linux desktop 、升级、各类 gui 软件的 bug ，浪费了太多时间。后来换到 mac osx 后，整个世界都安静了。

帮人折腾过几次 wsl 、wsl2 ，体验不太好（可能现在 issue 　 bug 有改善了？）
另外 sub 子系统与母系统是割裂的（比如 wsl 中用脚本自动种自签名证书就很麻烦）。我现在写自动工具、脚本，一般都不会特别考虑 windows 环境。

我习惯和想法跟你类似，我也写了 10 年的笔记，都是放 git markdown.

不过我没有你这些烦恼。

- 编辑：我使用的 vscode ＋　自带的 markdown preview ＋ Paste Image 插件，表格用 markdown table 的写法，附件就存其它地方只放链接（不过小文件直接放 git ）
- 存储同步：多个 git 　 repo 备份
- 阅读/分享：vscode 、自己用 katex(latex)+marked.js 写的纯静态（连编译都省了）
- 搜索查找：各类 shell tool(主要是 ag + regex )，由于文章目录本身就是按知识树分门别类，所以搜索很方便

我的方法是使用 map 按键映射：　将 command+c 映射到　"+y 复制到系统粘贴板，command+s 映射到保存

""""""""""""""""""
" Copy Quit Save Select
" config iTerm2 keys: Esc+Ac, Esc+As, Esc+Aa
" (注意：mac iterm2 中必须要改键，否则 vim/nvim 无法响应 command+c command+s ）
" mac vim 参考： https://stackoverflow.com/questions/23606892/vim-keyboard-mapping-problems-on-mac-osx
"""""""""""""""""""""
" Quit
nnoremap <C-q> :qa<CR>

" Copy
vnoremap <M-A>c "+y

" Save
nnoremap <M-A>s :up<CR>
inoremap <M-A>s <C-o>:up<CR>

" Select whole content
nnoremap <M-A>a ggVG

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
不想改键的话，就映射到其它 vim 能响应的按键

nnoremap <F2> "+p
inoremap <F2> <C-o>"+p
vnoremap <F2> "+y
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
这样做了后，visual 模式选中、鼠标选中后，都可以按 command+c 复制到系统粘贴板
---------------------------------------------------------------------------------------------------
BTW:
楼上提到的`:set paste` 　每次要敲一下命令我觉得麻烦，操作完后还要恢复`:set nopaste`（ paste 模式下自动编辑缩进会被关闭）.
即使使用`:set pastetoggle=<F10> ` 也只是还是麻烦，况且 nvim 还不支持这个选项

楼主已经自己确认了答案了：是这个 sql 库本身实现得有问题，跟 go 、json.Marshal 都无关。

在某种意义上还是 json 的表达能力不足导致的

## 不同语言的 json 库对[]byte 的处理
json 　本身无法区分 string 和 `[]byte`，只有 string 。

1. php 自己本身就没有`[]byte`，甚至连 dict/array 都不区分。直接回避了问题
2. python 　有`[]byte`, 但是不能 json 序列化, 如果是 utf8 就需要用 data.decode('utf-8') 要先转成 str
3. golang 　序列化`[]byte` 时用 base64 将它转成 string, json 反序列时则用相应的类型去关联`[]byte`类型
4. java , c sharp 跟 golang 处理方式一样的。

## golang 对 json 的支持

json.Marshal 方法:

1. json.Marshal 本身是使用了内置的 json encoder 默认使用 base64 处理 bytes, eacapHTML 默认为 true
2. 但是 json.RawMessage 本身带的 json encoder ，不会对 bytes 做任何处理，如果 bytes 不是 json 格式，就会报编码出错

某些 golang 　库实现，可能出于减少值复制，会用 bytes 去表达 string ，但序列化时就只能是 base64 　 string 了。

如果接收者不要 base64 string json, 解决办法有：

1. 自己先定义一个相应 string struct ，再将 bytes struct 转成 string struct ，最后 json 　序列化自然就不是 base64 了
2. 通过反射将 string struct/map 等 转成　 string map 再 json. 参考： https://github.com/ahuigo/golib/tree/main/spec/object/convert/objbytes2string_test.go

@w568w go 也有 urfave/cli 等工具提供一键生成 help message 、config 、type checking 。golang 算是 rust+python 的折中方案。

@sagaxu go 泛型库 lo 可避免写 for 、interface 转换。如果想用函数式的话，可试试 ibm 的 fp-go 库。

错误处理避免 if err 的话，可以像 bufio scan 的方法那样避免 if err 。不过平时开发一般还是 if err 简单顺手。另外错误 chain 是一定要支持，方便定位错误的调用栈

我是主力用 vscode 写 js/ts/go/python 好多年了，偶尔用来写 python/rust/java 。

最开始 java/python 的插件都遇到过很影响开发的 bug ，发 issue 后经过很长时间才解决的，不过目前使用良好（轻度使用）

这是逆 ECMA/TC39 　标准而行呀。es 不是不想简化，是要兼容，而且这些年语法上渐近的精进了不少了。

Deno 走 web 标准，做得很好，但是就因为跟 node/npm 不兼容，推广起来老费劲了

感觉 rust 的痛是暂时，zig 的痛是长期的

flex 各属性示例 https://static.vgee.cn/static/index.html

@a132811 chrome version 120 默认 line-height 1.15

你的例子中：分上下两个 flex row.　在 chrome version 120 下：

第一个 row ，最大的 block 身高＝ 35px*1.15 + margin(70px) = 110px
第二个 row ，最大的 block 身高＝ 190px

纵轴剩余: 500px - 110px - 190px = 200px, 两者平分各 100px 。

第一个 row：110+100 = 210px
第二个 row：190+100 = 290px (强制指定 item 的 190px 则不受影响)

－－－－－－－－－
BTW ，这个类似主轴分配规则，比如：

```html
<div style="width:400px;display:flex">
<div style="width:100px;flex-grow:1">item-a</div>
<div style="width:100px;flex-grow:2">item-b</div>
</div>
item-a, item-b 会根据 flex-grow 值，分割剩余的 200px(仅当存在剩余空间时)
item-a: 100 + 200px*(1/3) = 166.66
item-b: 100 + 200px*(2/3) = 233.33
```

我一直用的 vscode 自带的快捷键 go forward / go back
mac 的话，按 cmd k cmd+s 看一下你的快捷键是什么

chrome extension 的权限控制太水了，默认就是 On all sites 模式
不知道为什么不改成默认每个 extension 是 when you click extension 模式。

@keakon 嗯。
我主要是想确认否有简单优雅的实现(对调用方要简单/直接/安全)、以及更通用的 cache 库。

库本身的复杂性对用户是透明的，内部是否反射+泛型都 ok ，实际上本库的内部就是反射+泛型结合的

@keakon 如果输入用反射而不用泛型，那类型检查就没有了; 输出同理。

或许我没有 get 到你的意思？你是否可以给个伪代码，或者 demo ？

ps: 反射损失的性能很多场景可以忽略不计

@keakon 多参数的话不需要用反射。
其实以前我用反射实现过，使用起来更复杂、且会损失类型检查，目前用泛型实现就简单许多了。

如果是多参数的话，需要用包装函数（不需要反射）将参数将降维（示例： https://github.com/ahuigo/gofnext#cache-function-with-more-params2 ）

ps: 之所以没有封装成支持任意不定参或 any 类型的函数，是因为目前 go 的泛型参数不支持对约束再做断言。

如果你有更优雅方式的话，望回复告之，也欢迎 issue 、pr 。

开发效率只是一方面，有时需要关注以下问题：

- 维护成本、重构效率，如何最大程度避免重构火葬场
- 对底层内存的控制能力
- 内存常驻时的泄漏风除
- 类型隐式转换的风险
- 底层 extension 开发的容易性
- 底层库源码易读性、扩展性、调试性
- benchmark/profile 分析的易用性、成熟度
- 单测、功能测试的容易度

以上是 php 做得不如 golang 的地方，应该不完整。如果不需要考虑这些问题，php 当然也可以用得很爽。

BTW, php 相对 go 还有一个劣势:
如果想成为 php 专家，需要看一下 c 维护调试下 c 扩展，付出的时间、走的弯路要比 golang 多，毕竟 golang 的源码精简、历史包袱屎山很少