 |
kuanatV2EX 第 634702 号会员，加入于 2023-06-19 11:38:40 +08:00今日活跃度排名 1857 |
| V2EX 是否会考虑增加专栏功能？ V2EX • kuanat • 23 天前 • 最后回复来自 kuanat | 5 |
| 分享一些 Go 在全栈开发中的经验
11 Go 编程语言 • kuanat • 18 小时 47 分钟前 • 最后回复来自 kuanat
|
41 |
kuanat 最近回复了
3 小时 22 分钟前 回复了 busterian 创建的主题 › Android › app 反布局分析调试如何绕过 |
爆破思路的话，跳转无障碍应该是 startActivity(Intent) 的形式，把它拦截了。也有可能是带 Result 的版本，一起把 onResult 也拦截了。
正向思路的话，我不知道 dump activity 相关的 API 是什么，当然应用也不可能监听 API 的调用。只是这个 API 调用会有副作用，应用程序可以检测某个事件或者相关的状态变化来做出页面跳转的行为。
这就需要你逆向看下代码或者动态跟踪一下，目标程序可以利用的方式太多了。
正向思路的话，我不知道 dump activity 相关的 API 是什么，当然应用也不可能监听 API 的调用。只是这个 API 调用会有副作用，应用程序可以检测某个事件或者相关的状态变化来做出页面跳转的行为。
这就需要你逆向看下代码或者动态跟踪一下，目标程序可以利用的方式太多了。
5 小时 7 分钟前 回复了 fu82581983 创建的主题 › Kotlin › Kotlin 2.0.0 正式版发布了 |
写 Kotlin 可比写 Java 爽太多了，等 LSP 和 IDE 跟上，体验还会更好。
21 小时 27 分钟前 回复了 easychen 创建的主题 › 分享创造 › 为了自动化写了很多脚本，却总是边用边丢，所以我写了一个脚本管理工具 https://juejin.cn/post/7369211590363430923 |
@easychen #45
我之前的思路局限在脚本和工作流都是人在写之上，如果把视野展开，让 AI 来做胶水类型的工作（这本来也是语言模型的强项），现在就具备可用性了。
我也有尝试用 AI 来辅助生成功能性脚本，目前遇到的主要问题是没有很好的验证机制，很多时候需要人参与代码审计。另外目前基于提示词的运作方式接近于声明式编程，生成代码的实现方式比较不可控，更增加了人工判断的成本。
我之前的思路局限在脚本和工作流都是人在写之上，如果把视野展开，让 AI 来做胶水类型的工作（这本来也是语言模型的强项），现在就具备可用性了。
我也有尝试用 AI 来辅助生成功能性脚本，目前遇到的主要问题是没有很好的验证机制，很多时候需要人参与代码审计。另外目前基于提示词的运作方式接近于声明式编程，生成代码的实现方式比较不可控，更增加了人工判断的成本。
1 天前 回复了 meshell 创建的主题 › 程序员 › 有深入研究的 golang websocket 的大佬吗？遇到一个 30 秒自动断开的问题？ |
@meshell #24
继续往下查吧，wh.srv 可能做了些什么操作。随便猜一下，可能是某个 context 有 30s 的设置，超时之后直接在 http 层面触发了 defer Close() 之类的操作，这个操作完成了 tcp 层面 FIN/ACK 的关闭，结果导致 ws 层面是没有 opClose 消息的。
我看了一下 gobwas/ws 的代码，UpgradeHTTP 这里就把 net.Conn 的 deadline 给清除了（设置了 time.Time 的零值）。（既然是无超时，理论上每次读 message 的时候 err := conn.SetReadDeadline(time.Time{}) 这个重置就没有必要了，不过与你的问题无关）
继续往下查吧，wh.srv 可能做了些什么操作。随便猜一下，可能是某个 context 有 30s 的设置，超时之后直接在 http 层面触发了 defer Close() 之类的操作，这个操作完成了 tcp 层面 FIN/ACK 的关闭，结果导致 ws 层面是没有 opClose 消息的。
我看了一下 gobwas/ws 的代码，UpgradeHTTP 这里就把 net.Conn 的 deadline 给清除了（设置了 time.Time 的零值）。（既然是无超时，理论上每次读 message 的时候 err := conn.SetReadDeadline(time.Time{}) 这个重置就没有必要了，不过与你的问题无关）
1 天前 回复了 meshell 创建的主题 › 程序员 › 有深入研究的 golang websocket 的大佬吗？遇到一个 30 秒自动断开的问题？ |
@meshell #17
你给的截图里，最后一次客户端 ACK 确认服务端 Pong 之后，服务端主动发送 FIN ，说明断开是服务端的行为。
这个断开没有 opClose ，说明不是你的程序、也不是 ws 库的行为。
因为你是本地测试，也不会涉及防火墙。
由于 Ping/Pong 的间隔是 2s ，有双向通信，说明不是 Idle 相关的超时。也就是说，并不是 KeepAlive 等机制触发的先断开底层，再断开上层。
整个协议层面，在 ws 之下，还有（大概率）标准库 net/http ，再下层就是系统的 tcp socket 了。
我记忆中标准库 DefaultTransport 有个 30s 超时，查了一下 https://go.dev/src/net/http/transport.go 确实有，但是应该与你的问题无关。
正好你说你用的不是 http.client ，可以贴一下最小可复现的完整代码。因为之前的代码看不到 conn 的来源，可能是有哪个地方设置了超时参数。
你给的截图里，最后一次客户端 ACK 确认服务端 Pong 之后，服务端主动发送 FIN ，说明断开是服务端的行为。
这个断开没有 opClose ，说明不是你的程序、也不是 ws 库的行为。
因为你是本地测试，也不会涉及防火墙。
由于 Ping/Pong 的间隔是 2s ，有双向通信，说明不是 Idle 相关的超时。也就是说，并不是 KeepAlive 等机制触发的先断开底层，再断开上层。
整个协议层面，在 ws 之下，还有（大概率）标准库 net/http ，再下层就是系统的 tcp socket 了。
我记忆中标准库 DefaultTransport 有个 30s 超时，查了一下 https://go.dev/src/net/http/transport.go 确实有，但是应该与你的问题无关。
正好你说你用的不是 http.client ，可以贴一下最小可复现的完整代码。因为之前的代码看不到 conn 的来源，可能是有哪个地方设置了超时参数。
1 天前 回复了 meshell 创建的主题 › 程序员 › 有深入研究的 golang websocket 的大佬吗？遇到一个 30 秒自动断开的问题？ |
我没有用过这个库，随便猜测一下。
理论上 ws 这种应用层协议，没有主动关闭行为，是不会在自己层面关闭连接的。底层的 tcp 在没有 keepalive 介入的情况下，连接建立后能够无限保持。ws 库在收到关闭信号之后，会向更底层传递这个信号，于是 http 到 tcp 都会关闭相应 socket 。
上面的意思是，这个行为不是 ws 库和你的程序主动行为造成的。
我看到你说有定时发送 ping ，那么另一端是否有回应 pong 呢？如果没有回应的话会出现一种情况，接收方会保持正常，而发送方连续 30s 只有发送而没有接收，触发了更底层协议的某个断开机制。
正好 golang net/http 默认 transport 超时就是 30s 。如果上面的库是基于标准库实现的话，可能就是 http 层先断开了。
理论上 ws 这种应用层协议，没有主动关闭行为，是不会在自己层面关闭连接的。底层的 tcp 在没有 keepalive 介入的情况下，连接建立后能够无限保持。ws 库在收到关闭信号之后，会向更底层传递这个信号，于是 http 到 tcp 都会关闭相应 socket 。
上面的意思是，这个行为不是 ws 库和你的程序主动行为造成的。
我看到你说有定时发送 ping ，那么另一端是否有回应 pong 呢？如果没有回应的话会出现一种情况，接收方会保持正常，而发送方连续 30s 只有发送而没有接收，触发了更底层协议的某个断开机制。
正好 golang net/http 默认 transport 超时就是 30s 。如果上面的库是基于标准库实现的话，可能就是 http 层先断开了。
2 天前 回复了 shinelamla 创建的主题 › 程序员 › 为什么 golang 提倡 「接收接口，返回结构体」这样的原则呢？ |
之前的话题让我给带跑偏了，前面解释了 accept interfaces ，这里回归到 return structs 上面总结一下。
这句话的应用场景应该是 API 兼容性方面的，即返回结构体的代码写法可以避免很多不兼容的改动。
我之前在 Python 包管理的一个帖子里 https://hk.v2ex.com/t/1007645 简单提到过，像 Go 这样设计先于实现的语言，都会将包管理作为工具链的一部分。但这里的大前提是广大开发者合作，所有开源项目的包都尽量支持 semantic versioning 的版本号原则。包的提供者通过版本号主动声明 API 兼容性，包管理可以以很低的成本（非 NP 算法）解决依赖计算问题。
另一方面，Go 在 OO 抽象层面选择了组合机制而不是继承，从客观事实上也鼓励了包的复用。作为 Go 的开发者需要一个思维转变，就是任何一个包都可能依赖别的包，也可能被别的包依赖。后者这个情况就需要开发者清楚了解，什么情况下会造成 API 无法向后兼容。
在之前的讨论里已经明确过，Go 的接口是由使用方定义的，当这个使用方 X 的包变成其他包的依赖之后，X 就很难对这个导出接口做改动了，因为给一个接口增加新的方法一定是个非兼容的改动。
所以对于一般的应用场景来说，既然接口是调用方来定义的，那么这个定义只对调用方有意义，它完全可以是非导出的形式。这样 X 对于接口的改动都不会影响到下游的使用者。
这句话隐含的意思是 return structs (not interfaces)，针对的是从传统基于继承的语言转过来，习惯使用工厂方法而言的。
在 Java 中需要在多个实现中选择一个实例化的时候， 受到接口必须和实现在一个包里的限制，使用工厂方法实际上是暴露接口，隐藏对象（结构体）。在 Go 当中没有这个限制，实际是鼓励暴露结构体，隐藏接口。（当然技术上说一个非导出的接口只是形式上不可见，下游依旧可以根据源码隐式实现，这里不展开说了。）
Java 部分就不举例了，这里用 Go 模仿工厂方法模式来展示这样做的缺陷：
```go
type Storage interface {
____Get()
}
func NewStore(provider string) Storage {
____switch provider {
____case "A": ...
____case "B": ...
____default: ...
____}
}
```
项目使用过程中发现，还需要批量下载接口，于是想修改接口为以下形式：
```go
type Storage interface {
____Get()
____GetBatch()
}
```
无论在 Go 还是 Java 中，这个非兼容改动会导致大量的修改工作。
回到 Go idiomatic 的实现方式上：
```go
type storage interface {
____Get()
____GetBatch()
}
type MyStore struct {}
func NewStore(s storage) *MyStore {}
```
下游只依赖 MyStore ，上有对于 storage 的改动是 API 兼容的。
对于接口改动，需要对 A/B 的实现进行封装，改动也比工厂方法模式简单。比如可以独立另一个接口：
```go
type storageExt interface {
____GetBatch()
}
```
也可以用在结构体中嵌入（ embedding ）一个接口，其他部分封装一下：
```go
type MyStore interface {
____storage
}
```
这里有个技术层面的大前提，扩展结构体在绝大多数时候都是向后兼容的，而扩展接口永远都不是向后兼容的。所以暴露一个未来可能扩展的结构体，远比暴露一个接口更合理。关于这一点可以看我在另一个帖子 https://v2ex.com/t/1007845 当中的回复，中间提到两个讲座就是对这个问题的解释。
由于 V2EX 回复里面插代码太难读了，我这里就不举例展开了，顺着这个场景想象一下大概就知道增加功能这个需求所需要的工作量。就这个扩展接口的场景，Java 无论如何都要 X 主导这个修改，而 Go 里面 X 有需要就 X 来改； Y 如果有需要，把 X 的包引入进来，Y 也可以做这个修改。还是那句话，Go 的接口模式实现了工程层面（不仅仅是 API 层面）的解耦。
做个简单总结：
Java 工厂方法模式是为了解决只有 Java 才有的问题而形成的一般设计方法，而 Go 天然是不存在这个问题的。所以在 Go 中使用接口的原则和 Java 中是完全不一样的。
站在上游的角度，主动暴露接口一般是两个目的：一是规范使用，比如标准库把 Error 定义为接口；二是为文档服务，因为非导出接口是不会体现在 godoc 里面的。
站在下游的角度，只有在第一种情况才会主动使用上游接口，比如所有人都用 slog 的日志接口；使用上游接口等于主动为自己增加一个硬编码的依赖，正确的做法是使用上游暴露的结构体，然后封装并实现自己的接口。
顺便一提，由于太多下游错误使用上游接口的情况存在，很多上游开发者会在导出接口中包含一个非导出方法，这样下游就无法实现这个接口，上游就可以主动控制下游的使用方式，避免后期改动影响太多用户。
Accept interfaces, return structs 虽然只有四个字，但它代表的是思维模型的转变，想要说清楚实在是太困难了。这句话的核心思想我觉得 Rob Pike 的总结更恰当：Don't design with interfaces, discover them.
用我的话来总结就是，不要沿用 Java 面向接口编程的思路，先设计再实现，而是先实现，当发现有重复实现的需要时，再用接口来重构。在 Java 里面，没有设计到的功能重构起来代价非常大，所以变相要求预先做大量设计，而 Go 里面重构代价非常小，用到了再改。这是组合优于继承的体现。
这句话的应用场景应该是 API 兼容性方面的，即返回结构体的代码写法可以避免很多不兼容的改动。
我之前在 Python 包管理的一个帖子里 https://hk.v2ex.com/t/1007645 简单提到过，像 Go 这样设计先于实现的语言，都会将包管理作为工具链的一部分。但这里的大前提是广大开发者合作，所有开源项目的包都尽量支持 semantic versioning 的版本号原则。包的提供者通过版本号主动声明 API 兼容性，包管理可以以很低的成本（非 NP 算法）解决依赖计算问题。
另一方面，Go 在 OO 抽象层面选择了组合机制而不是继承，从客观事实上也鼓励了包的复用。作为 Go 的开发者需要一个思维转变，就是任何一个包都可能依赖别的包，也可能被别的包依赖。后者这个情况就需要开发者清楚了解，什么情况下会造成 API 无法向后兼容。
在之前的讨论里已经明确过，Go 的接口是由使用方定义的，当这个使用方 X 的包变成其他包的依赖之后，X 就很难对这个导出接口做改动了，因为给一个接口增加新的方法一定是个非兼容的改动。
所以对于一般的应用场景来说，既然接口是调用方来定义的，那么这个定义只对调用方有意义，它完全可以是非导出的形式。这样 X 对于接口的改动都不会影响到下游的使用者。
这句话隐含的意思是 return structs (not interfaces)，针对的是从传统基于继承的语言转过来，习惯使用工厂方法而言的。
在 Java 中需要在多个实现中选择一个实例化的时候， 受到接口必须和实现在一个包里的限制，使用工厂方法实际上是暴露接口，隐藏对象（结构体）。在 Go 当中没有这个限制，实际是鼓励暴露结构体，隐藏接口。（当然技术上说一个非导出的接口只是形式上不可见，下游依旧可以根据源码隐式实现，这里不展开说了。）
Java 部分就不举例了，这里用 Go 模仿工厂方法模式来展示这样做的缺陷：
```go
type Storage interface {
____Get()
}
func NewStore(provider string) Storage {
____switch provider {
____case "A": ...
____case "B": ...
____default: ...
____}
}
```
项目使用过程中发现，还需要批量下载接口，于是想修改接口为以下形式：
```go
type Storage interface {
____Get()
____GetBatch()
}
```
无论在 Go 还是 Java 中，这个非兼容改动会导致大量的修改工作。
回到 Go idiomatic 的实现方式上：
```go
type storage interface {
____Get()
____GetBatch()
}
type MyStore struct {}
func NewStore(s storage) *MyStore {}
```
下游只依赖 MyStore ，上有对于 storage 的改动是 API 兼容的。
对于接口改动，需要对 A/B 的实现进行封装，改动也比工厂方法模式简单。比如可以独立另一个接口：
```go
type storageExt interface {
____GetBatch()
}
```
也可以用在结构体中嵌入（ embedding ）一个接口，其他部分封装一下：
```go
type MyStore interface {
____storage
}
```
这里有个技术层面的大前提，扩展结构体在绝大多数时候都是向后兼容的，而扩展接口永远都不是向后兼容的。所以暴露一个未来可能扩展的结构体，远比暴露一个接口更合理。关于这一点可以看我在另一个帖子 https://v2ex.com/t/1007845 当中的回复，中间提到两个讲座就是对这个问题的解释。
由于 V2EX 回复里面插代码太难读了，我这里就不举例展开了，顺着这个场景想象一下大概就知道增加功能这个需求所需要的工作量。就这个扩展接口的场景，Java 无论如何都要 X 主导这个修改，而 Go 里面 X 有需要就 X 来改； Y 如果有需要，把 X 的包引入进来，Y 也可以做这个修改。还是那句话，Go 的接口模式实现了工程层面（不仅仅是 API 层面）的解耦。
做个简单总结：
Java 工厂方法模式是为了解决只有 Java 才有的问题而形成的一般设计方法，而 Go 天然是不存在这个问题的。所以在 Go 中使用接口的原则和 Java 中是完全不一样的。
站在上游的角度，主动暴露接口一般是两个目的：一是规范使用，比如标准库把 Error 定义为接口；二是为文档服务，因为非导出接口是不会体现在 godoc 里面的。
站在下游的角度，只有在第一种情况才会主动使用上游接口，比如所有人都用 slog 的日志接口；使用上游接口等于主动为自己增加一个硬编码的依赖，正确的做法是使用上游暴露的结构体，然后封装并实现自己的接口。
顺便一提，由于太多下游错误使用上游接口的情况存在，很多上游开发者会在导出接口中包含一个非导出方法，这样下游就无法实现这个接口，上游就可以主动控制下游的使用方式，避免后期改动影响太多用户。
Accept interfaces, return structs 虽然只有四个字，但它代表的是思维模型的转变，想要说清楚实在是太困难了。这句话的核心思想我觉得 Rob Pike 的总结更恰当：Don't design with interfaces, discover them.
用我的话来总结就是，不要沿用 Java 面向接口编程的思路，先设计再实现，而是先实现，当发现有重复实现的需要时，再用接口来重构。在 Java 里面，没有设计到的功能重构起来代价非常大，所以变相要求预先做大量设计，而 Go 里面重构代价非常小，用到了再改。这是组合优于继承的体现。
2 天前 回复了 uiosun 创建的主题 › Web Dev › 请教： WebSocket + Protobuf 做服务，如何定义路由 |
这种通信场景一般没有路由的说法吧，都是用协议这个词。
如楼上说得都挺好了。我有个建议，你可以看看用 unix domain socket 做 IPC 通信一般是怎么做的。ws 就是把本地变远程，protobuf 就是 socket 的具体实现（协议/路由）。
在 web 编程里是匹配路由然后把请求交给对应的 handler ，在 socket 编程里硬要说路由或者协议的话就是某个字节代表特定的类型，然后每个类型有一个专门的 handler 来响应。
如楼上说得都挺好了。我有个建议，你可以看看用 unix domain socket 做 IPC 通信一般是怎么做的。ws 就是把本地变远程，protobuf 就是 socket 的具体实现（协议/路由）。
在 web 编程里是匹配路由然后把请求交给对应的 handler ，在 socket 编程里硬要说路由或者协议的话就是某个字节代表特定的类型，然后每个类型有一个专门的 handler 来响应。
2 天前 回复了 wzhings 创建的主题 › 信息安全 › [求助] 如何有效地保存用户名和密码? |
Select Language