@opengps 确实需求不是特别高

@frank42a 场景简单：只做缓存不需要高级的数据结构

使用老年版，立无

@yeqown https://goproxy.cn/#self-hosted-go-module-proxy 这部分

你需要的不是私有库，而是一个代理啊，goproxy.cn 了解下

#5 正解，文档里的 example 和你的场景完全一致 https://pkg.go.dev/encoding/json#example-RawMessage-Unmarshal

PGV 已经够用了

解决了么。。。

@shyrock 那就更应该考虑解耦的方案了，毕竟都有几十个单据表格了，再有新增也不奇怪，侵入业务的方式不可持续。在变更事件发生时去 创建 /更新 “待办”（或者这里更像一个工作流？），创建时再根据业务资源（不同的策略）筛选出参与人并绑定。

这样的话，“待办” 就独立了，再去做待办的各种接口也比较方便。

@coderluan 外部中断信号

目前看起来是猜测已经够多了只差验证了，我提供一个验证的思路：利用 BPF 技术追踪下 os.Exit 和 panic 调用，能够定位到底是因为哪一种方式导致程序退出的。

还是花钱找一个专业验房的吧，有问题的话，拿出一个验房报告也比空口扯皮来的简单直接。。。这事就好像打官司可以自己上，但是请律师就是会省心&安心得多。

@totoro625 密码保存后想要自动填充的可能都是明文存储，毕竟加密后的密码没办法给第三方使用。就算它采用加密算法，那多半也只能选择可逆加密，太看服务商的良心了

其次，看你的错误信息，我猜测你这个理应该连握手都没办法完成吧～（协议问题），你测试结果有正确的响应吗？

@Pengxiguaa
这样反向代理 WS 是不行的吧，你想 HTTP 握手后升级到 WS ，HTTP 客户端怎么和 WS 服务器通信呢？协议都不一样了～
https://github.com/yeqown/fasthttp-reverse-proxy/blob/master/ws_reverseproxy.go#L71 供参考

把项目删掉

@yongchiu 从我的角度出发，mask response 字段是为了减少客户端的使用成本，同时节省带宽和减少不必要的计算（提升服务端性能）。但是，如果再客户端自己做的话，那么这两个目的都没有达到 ～ 所以我认为没有意义

@yongchiu 可以啊，就是客户端使用 FieldMask 而已，把屏蔽的处理过程放到了客户端而已（客户端获取到 response 之后，调用一下 XXX_FieldMask.Mask(resp) 就会屏蔽不需要的字段，客户端后续的处理中再获取这个字段时就是空值了）只是这样做几乎没有意义～

@mcfog 哈哈，是的，所以避免人为传 string 出错，我就想直接从 proto 生成近乎所有字段的 Mask_xxx 函数来使用。兼容性方面得看自己需求是什么，如果频繁变动的确实不太适合加这种功能；性能的话，我个人感觉是如果有要求的话，最好是自己去判断 “某些计算和调用” 相关字段是否需要返回，应该会降低某些场景下的延迟，但是这样势必侵入逻辑，有利有弊吧