# 28 少打两个字

这个问题和 什么样的排名算法, 能够让未来总是一直涨的股票得分靠前? 有什么区别吗

这个问题和 什么样的排名算法, 能够让总是一直涨的股票得分靠前? 有什么区别吗

@Ayanokouji github.com/pkg/errors 这个库还能再战。其实自己定义也可以，实现 error 的 struct ，增加一个 Wrap 函数，参数接受一个 error ，函数体，runtime 拿调用栈，将结果保存在 struct 的成员变量，这样就可以用了

可能是最佳实战的做法是，你调用了标准库，或者第三方库，这些库返回 error 之后，你应该先用一些第三方 error 库 wrap 一下，主要目的是记录一下 error 发生的调用栈，这样上层什么位置拿到 error ，都能打印出来这个 error 是哪个位置发生的。还有一种，目的类似的做法，不记录调用栈，而改为附加一个错误码进去，这样上层的任何调用者也可以知道 error 哪里发生的，不过维护错误码这种方式维护时间越长，越容易搞混乱，导致排查问题困难。
原则上，只要不是本工程的代码生成的 error 都进行一次 wrap ，然后向上 return ，如果没有最上层，则进行错误日志打印。

你需要考虑
奖项的现场增删改
5 个中奖人，4 个不在，1 个重抽
抽完之后，已中奖的人，现场新增的奖项可以参加，下轮抽奖不参加
当然，喊开始，大屏幕播放动画，停，这些动画必不可少
在一轮奖项人数超多时候的展示问题，比如一轮 50 人中奖，大屏幕如何展示

技术上，最好私有化部署，防止网络出现故障。部署设备需要准备备份。抽奖系统使用有线网络，人多了，无线各种干扰特别多。抽奖过程一定要多检查测试，严防出现抽奖不公平发生。



最简单的还是听从大佬的建议，够买商业版，一个是商业版理论成熟度更高，另外一个，出问题不用你担责。8000 人现场，小 bug 都可能造成严重后果。

最后就是多彩排测试，你每多一次测试，出问题的概率就会变小。😏

java 是 try catch ，只需要处理 exception 。go 里面有两种一种是 panic ，一种是 error ，panic 通过 recover 捕获，error 就是带在函数返回值里面返回。可能是最佳实战的做法是，你调用了标准里，或者第三方库，这些库返回 error 之后，你应该先用一些第三方 error 库 wrap 一下，主要目的是记录一下 error 发生的调用栈，这样上层什么位置拿到 error ，都能打印出来这个 error 是哪个位置发生的。还有一种，目的类似的做法，不记录调用栈，而改为附加一个错误码进去，这样上层的任何调用者也可以知道 error 哪里发生的，不过维护错误码这种方式维护时间越长，越容易搞混乱，导致排查问题困难。
楼上有说，将 error 转换 panic 的做法，这样做看起来比较爽，不用多余定义 error 返回值，不用 if err!=nil 判断，只需调用入口 recover 住，但是这种做法，不是主流做法，至于为什么不主流，知道的可以解释下🤭。

@shebaoting 录一段视频，口里按照固定格式，我 xx ，今天 xx 时候，投 xx 票，然后进行投票。投票平台，每条投票明细，都可以查询，并且每条记录都有录制的朗读声明视频，供大家审计。平台必须公布所有投票明细，包括弃权的。

另外
投票人不重要计票人决定一切 --斯大林

当重庆市市委书记，或者重庆市市长也行，要实在不行，当个武汉市长也行吧

op 描述问题的方式很有问题，这个主要是为了防止，用户被诱导，比如线下推广人员诱导点这，点那，然后进行了用户可能不知情的操作。参考信用卡怎么防止用户被诱导办了信用的卡。
40 楼说的没错，这就是意愿认证
> 语上这个叫做意愿认证，实际的应用中，意愿认证不可能以静默的方式实现
> 方式可以是：短信验证码、签名、音视频录制等

这个必须点赞

> 建议用 https://github.com/rust-cross/cargo-zigbuild 或者 https://github.com/cross-rs/cross 静态链接 musl ，不要静> 态链接 glibc ，可以动态链接 2012 年的 glibc2.17 ，就可以在主流相同指令集的 linux 上跑起来，比如 cargo zigbuild > --target aarch64-unknown-linux-gnu.2.17


@capric rust 编译最佳实战 👍️

@dogfeet zigbuild 我试了下，使用 rustls ， 指定低版本的 glibc ，比如 2.22 ，那大多数服务器都可以兼容，不知道这样做有没有什么坏处

@adoal 感觉有点道理


@dogfeet cargo zigbuild 没试过，我是用 https://github.com/cross-rs/cross 交叉编译。zigbuild 不静态链接，到运行的机器容易提示找不到对应 so 吧？静态链接，最佳实战应该就是 musl 了。



@kagenomirai
glibc 众所周知是不可以静态链接的，这个我见识短，之前不知道。
和 lua 比不合适，lua 需要依赖解释器。rust 和 golang 编译输出都是可执行程序，所以它们比较有可比性。编译和链接这块 golang 难道不比 rust 方便？ go buid 指定 os 和 arch ，就可以了。

@hingle 列的都是客观事实

@wolfsun 上来就开喷，不进行一下准备工作吗？比如列一丁点事实？

@aloxaf
我测试了一下，musl 静态链接这个代码确实没有问题。linux 静态链接还是得 musl 。
@dilfish 下次可以试试 musl 静态链接


@virusdefender 看来 glibc 确实是不能静态链接。即使静态链接编译成功也是假象，段错误在运行时等着。

建议
public <T extends V> T get(String cacheKey,K key){
Cache<K,V> cache=cacheMap.get(cacheKey);
if(cache!=null){
return (T) cache.get(key);
}
return null;
}

你是要限定 V 的类型范围，因为你已经限定了 cache 的 value 是个 V 类型。传 Class<T> clazz ， 那你的 V 类型还不如直接定义为 Object 。另外你的成员变量 cacheMap 会有并发安全问题，当然如果 CacheHelper 不会有并发问题，那可以忽略并发安全问题

@kneo

> 栈的特点就是动态增长。因为函数调用需要把子函数的存储也分配到这个栈上。函数的嵌套越多，需要的内存就越多。

> 栈空间不够用就需要重新分配内存并且把旧的栈数据复制过去。（这里指的是虚拟线程，原生线程收到操作系统限制> 可能无法修改栈大小。）

> 如果初始化栈过小，频繁的扩容会影响性能。

> 初始栈过大，会造成内存浪费。

> 2KB 是一个性能权衡的结果。

> 您可能需要找一些函数调用和栈内存的示意图看一下。不一定非是 GO 的。

我找了一些函数调用和栈内存的示意图看了下，2kb 的栈空间是用来保存现场的，go 做了一次预分配，在 op 提到的测试方法，这样预分配在内存占用方面确实会吃亏，反而动态堆分配的会占优势。