你看，标记的其实是同一个函数，并且是从 [1] 开始递增的，所以结论只有一个

这标记的是这个方法递归的深度

"独挡一面” 应该不是要求技术水平（或者不只是要求），而是一个综合工作能力的要求，说到笼统点：能否有把你工作范围发生的各种 正事，破事 落地，不让事掉地上
细化下来可能有：

- 技术方便： 解决问题的能力，学的技术再多，也一定会遇到你经验以为的 事情/技术/要求/bug ，能否正面面对技术挑战/疑难
- 团队协调：能否协调团队的目标与自己目标，驱动团队工作（不一定要是 tl ）

协调外部/要资源/向上管理....

不要求每项都很强，但要做到能在你的位置上推进事情

“你们是不是有自己定义的规范？”

目前看到的信息只能说，这代码与业界通行的几种规范都不一样，还不能说他不规范，万一有内部规范呢？

不过你们这规范一致性不太好啊，为啥独独 `id` 是 lowercase 的

现在 go 错误处理比刚出来的时候好多了，繁琐是有点，但是没啥心智负担（对写应用来说），只是和 rust 比起来显得有点草率，基本和 rust 无脑 anyhow::Error 一样

@sadfQED2 依赖注入多好啊，刚改了，极大解放

不过我不喜欢 一堆 do vo dto 单纯不喜欢这个名字，有必要还是会用类似的分层方式

1. 先找个能满足你需求的 kv store, 不限制语言，看看你需要的 feature , 需不需要 事物, 快照 等, 比如 rocksdb
2. 看看这个库有不有 python 的 bind
3. 如果没有，可以考虑 PyO3 自己简单撸一个

而对于那些已经编译过的产品的漏洞发现 并不像你想的那么难，开源软件的漏洞挖掘也没有你以为的 看源代码那么简单, 有几个问题会导致这个情况, 1) 代码量太大，即使开源软件也不太可能一行行去看代码, 往往会带有一定目的性 2) 肉眼可见的漏洞往往是少数，这种漏洞基本上通过一些 代码质量工具 就能有提示, 3) 更多的需要你对 计算机\目标平台\目标软件业务 有或多或少的了解, 简单说既要全局又要细节, 思维模式上和正向开发的思维是不太一样,

-- 需要反汇编去分析吗？某些时候需求，某些时候也确实是要分析一些详细逻辑的，但会带有一定的针对性，下面说
-- 有哪些套路: a) fuzz, 这是现在漏洞发掘主要的手段之一, b) 总结历史一些漏洞出现的 pattern ，再依据这些 pattern 或依据人工或依靠工具 去发现类似的漏洞, c) 某些时候也可能要开一些脑动, 整体就是，搜索空间无比巨大, 要用一些方式来提高效率


漏洞的详细情况，产品方一般是不会说的，一方面，有确实延缓传播的意图，二一方面有法律法规上的限制，如果只是修复，看产品商就可以了

一些历史的有利用价值、有启发性、有意思的漏洞, 你 google 一下还是有的，应该不难
比较新的，或者比较鸡肋的，利用有难度的（很多漏洞只在理论上存在利用可能），影响范围小的 可能就没有了

不好吗，感觉挺好啊，我用 win10 也开了合并，可以搭配下三方的窗口管理器

怎么就得出`不会有什么好处` 的结论呢？最多就是他解决的不是你的问题而已

@thevita 是指 golang 的 sql 包

真要说起来,
@hxtheone 是的，就是 type system 不一致的原因，类似的情况其他语言也一样会存在，同样的问题 sql 也一样存在，完全可以参考 sql 的解决方案呗，扯半天扯不到点上。

问题还是 go 的 部分 value type 没有 null, 这点与 json 不一致，要弥合这点，

1. 让 go type 去 match json ，可以引入 Null* 的 type, NullString, NullNumber 什么的,
2. 让 json match go type, 依然通过 NewType 实现 UnmarshalJSON 来验证数据呗

@unco020511 mr/pr 不是 gitlab/github 的功能么, 这还用插件?
---
感觉没必要完全 gui/cli, 这两者对 git 来说又不是互斥的选项, 我都是一起用的，那个顺手用哪个， 比如解决冲突就会选择切换到 gui 来

国内环境，服务行业节假日不放假不算什么吧，（如果你是后端，那确实福报）

@Morgan2 因为他故事框架没啥敏感的吧？是 R 级片 是不是因为有少量情欲描写？，这部分事实上 在部分国家上映的时候都有调整

《奥本海默》不难懂吧，不需要什么 物理/量子力学 的背景知识，毕竟纪实电影嘛，无非叙事方法上 显得可能有点乱？，但也还好，我是开幕了几分钟才进去的，经历 几分钟 懵逼也能掌握的叙事的方式，后面看起来就没压力了，不过我确实不怎么喜欢，对这种纪实类型比较无感，但并没有让我昏昏欲睡，诺兰还是 nb 的

aws 国内可以用吧？我就用国内信用卡啊，还有电话推销呢

看业务需求，不要被“脚本”二字束缚住了手脚，关键是业务需求是如何的，并不是一定要是一个 script, 因为 `脚本` 本身还是个技术 term, 因为这限制业务分析舍本逐末了

作为一个 平台，对外的提供可扩展能力, 其实目的也不一样啊

是需要 一个 glue lang 来调用平台 api, 实现灵活的逻辑呢？ ( 这可能比较符合传统很多 script 的定位, 比如 lua 定位就是作为 glue lang 存在)

还是需要接入其他三方生态（ 比如允许加载 自定义 jvm class 很多 jvm 生态里的东西也许有可能接入）

等等...

总的来说，具体问题具体看，心态开放点呗，尽量不用自己领域的知识向外，不然很累。

我很喜欢
--
如何反馈:

Help-> Submit Feedback...

or

取消订阅，这样你的意见就反应在他们的营收上了 QAQ