https://go.dev/play/p/jO_UICpyO9X
看起来 stdin(也许是其他)是 eof 的.

看你怎么理解杠杆了.
比如 nvda,你 1 option = 100 股.
买 1 个 option 可能也就几块,然后你有 100 股或者按 130 算 13w 美金的话,确实问题不大.

前提是你有 13w 美金的时候能忍住只买 1 单位 option.

1. long call/put 只是 expired 不强制 exercise 的话,确实只亏 option 本身的钱. 但如果强制 excise 的话,比如你 1 option 对应 100 正股,那么到期后你就得承担对应方向的 100 股的成本.所以叫杠杆.

2. short call/put 相当于你是 1 的对手盘.亏损是无上限的.
举个例子,你 short 了 1 option 的 target 正股 10 块价格 1 块的 call option,那么现在手上有了 1 块,同时有着 1 块 liability.
如果比如股价涨到 15 块,那么对应的原来 10 块的 call option 可能到 5 块,也就是现在你手上有 1 块,但是同时有着 5 块的 liability,500%.

3. 涨幅巨大是指 option 自身的价格.比如 2 里的例子.
更极端的比如 150 块的 nvda put,假设价格是 20 块(以当前 130 的水平粗略算).
那么当股价到 135 的时候,put option 应该在 15 块. 相比股价 5/130 = 3.8%的范围,put option 在 5/25 = 25%.

有没想过,你父母当时可能也是这么想的.

看 request/response 的大小是什么区间了.
如果不大的话相比可能 HTTP 协议本身的 overhead 就很冗余,可以考虑换协议.

说句不好听的,考研失败+空窗两年,你凭什么觉得你的未来规划还在你的掌握之中?

刚看了下现在支持 lua 动态分发了.
https://www.envoyproxy.io/docs/envoy/latest/configuration/http/cluster_specifier/lua

配对应的 cluster upstream 和 endpoint 应该就行了吧.

没有什么是长青的,看自己兴趣能不接受以及可能更重要的,哪个的收入回报比较容易保证温饱.

你可能还需要打听下租户难缠不难缠...

@nzynzynzy 感觉你的疑惑点可能在于有 n 个 transaction, m 个 invoice 要冲销, m>=2 的场景.
在 multi invoice 的情况下,不通冲销策略造成的余额可能不一致(不确定)?

其实可能是个背包问题?
合并若干个可能是顺序的 transaction 使它满足>= 某个 invoice?

看着像币圈侧链/次级账户交易合并回主链的操作...

你合并 transaction 的时候检查更新余额看有没超不就行了?

旷工这条除非你能提供你所说的不用打卡的证据,不然没什么能够支持你的诉求.

本质上线性变换 T 和矩阵 A 是两个不同概念.
这个定理的目的就是 bride 这两个概念,使得你所谓的抽象的 T 能被一个 A 乘来表达.

从而构造了你红圈的那句表述.

/的一个问题是有时候你做自动化脚本会遇到路径问题.

比如你根据分支名字去打包,然后期望的是文件实际路径变成了 nested 的目录.

生成结构挺清晰的其实.

初始化.
单独 core function
集中异常处理,甚至看得出框架原型结构可能是上报到个异常收集中心.

docker run 个 spark shell...

同时用有什么问题?

真要升级风险也小.