V2EX › faceair 的所有回复 › 第 12 页 / 共 65 页

如果是毕设的话感觉不用特别在意协议开销，并不用像生产环境那么扣性能。websocket 创建连接是 http upgrade 来的，所以第一个请求略大一些，后面协议传输的时候对比裸 tcp 的话每个数据包大约两个字节的 websocket 协议头。
协议可以直接选 mqtt 就好，发布订阅模式，满足你的 IM 需求，mqtt 可以直接走 tcp 也可以走 websocket。

2018-03-08 18:48:54 +08:00

回复了 iYu 创建的主题 › 全球工单系统 › 招商银行 iOS App 转账回执被传改

我遇到过类似的问题，最后确定是微信的 Bug
你尝试用美图秀秀随便分享一张图片到微信看看是不是还是这张，另外这张图你之前是在哪见过吗？

2018-02-24 10:56:40 +08:00

回复了 eccstartup 创建的主题 › 问与答 › 白名单和黑名单的交集一般是怎么处理的？

匹配的时候一般优先过白名单？

2018-02-14 20:23:11 +08:00

回复了 weakish 创建的主题 › 问与答 › 有没有臃肿版的 Go 标准库？

有个 typo，上面有个堆写成栈了

2018-02-14 20:08:23 +08:00

回复了 weakish 创建的主题 › 问与答 › 有没有臃肿版的 Go 标准库？

@skadi #6 没啥好笑的啊我的全部思考过程是这样的

比如 #7 给的这个例子里返回了一个 hash 的 byte slice，这个返回值就极有可能生成到栈上影响 GC 性能啊
生成我们想要的 hash 值可以粗略的认为有两步，第一步是计算，第二部将计算结果转为期望的编码（ hex 或 base64 ）标准库写法这么冗长的原因将这两步拆开了，允许你自己将这两步的结果 slice 自己先塞进去，避免标准库把对象分配到堆上

我前面跟 @orzfly #3 说想错了的意思是，两者确实不是强关联的
比如我前面描述的两步是可以捏到一起的，第二步的结果的 slice 允许当参数传入就好了所以 #7 的 API 可以大概设计成

result = make([]byte, 0, 64)
err = sha256.SumHex(data, result)

2018-02-14 15:54:45 +08:00

回复了 weakish 创建的主题 › 问与答 › 有没有臃肿版的 Go 标准库？

@orzfly 🤔 是我想错了，这么说好像确实不合适

2018-02-14 15:28:42 +08:00

回复了 weakish 创建的主题 › 问与答 › 有没有臃肿版的 Go 标准库？

行数可以变短但必然带来额外的开销(内存分配)，一般 go 作为高性能后端对这些都是很敏感的

2018-02-14 14:42:39 +08:00

回复了 40huo 创建的主题 › 分享发现 › 头脑王者借着知乎复活了？

之前是合作现在是收购了？ (纯猜测，不知道内情

2018-02-05 15:25:17 +08:00

回复了 mmnnyycc 创建的主题 › 程序员 › go 关键字之后，怎么不输出了？

虽然 goroutine 没退，但你 main 函数执行完整个进程就退出了你可以在 main 结尾加个 select {} 阻塞一下