so 加载在哪个进程就调试哪个进程, attach 上去就行了

工资的个人所得税按全年收入实行阶梯税率（只是工资部分，其他的意外所得统一 20% 应该是）
但因为是按年薪计税，就涉及到怎么交的问题，现在的做法是由发你薪水的单位每月代扣代缴，要是改成自主申报，不更得哭爹喊娘
就是每月按全年累计收入计算，这只是一种方便的会计计税的方式而已，
没发现每年到后面几个月，到手工资下降得厉害么，都没疑问？

就像上面大家说的：这种带扣预申报的方式在换工作的时候，收入累进回重新计算，但 这只是 **会计规则**，相当于重复享受了两遍 部分 免税/低税的 收入，当然最后申报的时候要补缴回来

NTFS 也可以把 volume mount 到 folder 的吧，把 user 单独挂了 volume 不就行了

加个 current_version(user_id, business_type, current_version) 表，锁这个表来实现

inc current_version, 和 insert 放一个事务里，也不用去 max(version) 了-- 就是不知道业务有不有其他要求

-- 当然本质上跟 分布式锁，或者 redis 锁是一样的，开场景吧，我觉得大部分用不着分布式锁

@9fan
嗯.......

你这里的 “文件无法进行业务上的区分” 是啥意思, 是上面说的 “哪个对应哪个文件”，没问题啊

给个 curl 你试试就知道了: curl http://localhost/upload -Ffile1=@log [email protected]

不知道是不是理解错了，我感觉你被网上的信息误导了

嗯，，啥意思，是我没理解对么，“后端必须知道哪个对应哪个文件” 是啥意思，就是后端能上传多个文件？，，

这本来就可以啊，挑战在哪？？

@thevita "同一个应用可能依赖相同的库，这个相同的部分就不用重复安装了" => "不同应用可能依赖相同的库，这个相同的部分就不用重复安装了"

我看 op 的主要疑惑应该是在于，用了 Android 的应用模型来理解 so 的“共享”的作用，这里的应用不一定是 android 应用

这里 op 可以看看传统 linux/windows 的 应用模型就比较好能搞明白 (因为这本身设计也主要是基于此的)，以 linux 来说，应用（包含应用主程序） 和 库（包含一系列 so ）是分开安装和管理的，同一个应用可能依赖相同的库，这个相同的部分就不用重复安装了

Android 正常的开发模式下（指 用 ndk 编译好 so 打包进 apk 中进行分发），因为 Android 应用沙河的存在，共享这个 so 是做不到的，这里 so 的作用就是用来实现动态加载，对接 JNI 的 api 而已.

然后呢，是不是可以直接用 math/rand 了？

同 1 楼，放 ctx 里,

开启事务:

...
transactions.RunInTx(ctx, fun(ctx context.Context) error {
// biz logic
})
...

repository 实现

func (r *Repository) FindXXX(ctx context.Context, id string) (xxx, error) {
return transactions.Db(ctx).Find(ctx, ...)
}


事务对业务的侵入性也小，有一行代码的事

你需要个 DPI, 比如 suricata, 给你解析到协议(会重组 tcp ，不用你自己“根据一段特征流量从当日流量匹配出特征流量出现的时间点”, 把各种你可能需要的内容提取出来，也能自己加些检测规则)

产生的数据流，要可用，可后面接写时序分析什么的，自由发挥

看性格，我觉得很舒服

@thevita 在前公司也是有入网要求，不过是自己产品，一个是终端行为，二一个是为了解 TLS （在我看来，我即便相信公司不会滥用，我也不相信它能把这些数据保护好，“不是不相信你的人品，是不相信你的能力”），发展到后来，1 ）逆向了起心跳逻辑，自己写个程序发包，但不是很稳定，2) 干脆买个 hpc 来当路由

起个虚拟机，把网卡直通给他，在里面装软件，物理机通过他上网

我也觉得纠结这些意义不大，这里就说是 "golang 实现了用同步的语义（语言层面）使用 IO 多路复用（ API/系统调用层面）"

如果将来 golang 的 io 实现使用 io_uring 的话还可以说: "golang 实现了用同步的语义使用异步 IO “

异步/同步 也可以统一嘛。

申请个开发/测试机，制度成本当然要公司承担

有数据吗？，有的话上 AI