跟职业没关系，只是从事这个职业的大多要么是当下的穷人，要么是穷出身而已。真的钱罐子里泡大的那一批程序员，出手也一点都不抠。

实际上其它职业也一样如此，穷出身的公务员、医生、教师、销售、公司老板，一样都很抠。

单就 OP 提的这个方案，看起来应用价值不大

对代码进行重构的代价，写代码本身只占很小的一部分，代码重构后的测试、发布流程才是大头。
如果我都能接受对代码进行重构了，其实用 Go 、Rust 之类的语言把热点重写一遍，内存占用就会显著下降了（身边挺多这样的实践）；但如果我没打算进行大规模重构，那单改一块热点代码来适配 GC ，除非收益真的特别大，不然很难想象这样的技术改造能通过评审……

有一个技巧是 few-shot fine-tuning ，就是你在 prompt 的时候，给大模型一个样例。

就是：
你是 XXXXX ，你的性格是 YYY ，你会输出什么什么格式。

然后给一个或几个样例：
当我给出 AAA 的输入时，你的输出应当是 BBBB 。

这么一通下来，对于不是太复杂的需求，一般就能做到比较好的约束了。

当然，如果你还是对输出格式不放心，可以自己再外面再套一层校验，然后在输出结果不对时，用预设的 prompt 调整输出重新回答。

@jimrok 可以。Ghidra 已经有类似的插件了。不仅能解释，还能做可读性优化

变量类型那一条，应该说是 IDE 太烂了。Java 也支持 var ，但像样点的 IDE 都可以把变量类型显示出来的，甚至包括 VSCode 装对了插件都可以

（看到楼主用的是 Goland ，我很难想象都 2024 年了 JB 家的 IDE 居然连这种基本功能都不支持么？

@zhuangku556 说实话从你报的菜名看，玩的游戏恐怕真的不多。

要适配各个机型的话就每个机型（至少每个牌子）都得来一台，不搞深度适配的话，无脑 Pixel 。

@drymonfidelia 不方便在哪里？不管多少位的大整数，转字符串也就一两行代码的函数的事情啊。又不是让你去做大整数运算。

@erwsd32ew 头部大厂客户端大部分是局部加固的，主流做法是虚机方案。如果完全不做加固，黑产真的能把他们底裤都脱掉。

客户端安全的原则是：破解利益<破解成本 === 安全。

国密 tls 有现成的库，别想不开自己写……这玩意儿正确实现基本破解不了的。

@keakon 你这个问题 recall 太低了，完全可能把会用 Python 的人也一起筛掉。

这种 corner case 的问题真的很好提，比如如何给 Python 的 object 类新增方法。但出题不是为了筛人，而是为了考察对方的水平。

@Jirajine 你这不就是反诈断卡的思路么……没有用户自然就没有黑产了。

虽然大家经常吐槽互联网大厂不干人事不把用户当人吧，但他们真的比你想象的更注重用户体验

@Jirajine 现实中的需求是：“一个正常用户想怎么看怎么看，而且你不仅要区分是不是由 APP 发出，还要区分是不是由一个正常的 app 发出”

而事实上反爬也不是通过卡顿来实现的……群控、accessibility 、截屏这些都在反爬的对抗清单里，你试试就知道了，不是说做不了，但绝没有你想象的那么简单。服务端限流也会做，但光靠这个是达不到目的的。

“电商应用为什么要信任客户端”。这个问题在反爬这个场景就很滑稽，实属是外行对于安全的一种刻板印象了。你稍微想一想就明白了，爬虫对抗这个场景下，你如果在客户端完全没有可信基，那整个对抗都可以直接放弃了。因为爬虫获取的本来就是客户端通过正常途径就能获取到得数据。

fd 泄露好歹只是泄露，要是 gc fd 变量的时候直接把 fd 关了，那好多应用恐怕跑都跑不起了了……

这种东西对通用 GC 来说就是不好处理的，refcount 和 RAII 机制都会更顺滑一点。using 相当于就是手动引入 RAII 了。

我个人感觉瑞幸的冷萃口味比它的冰美式强得多