重载使用的方法好像是编译时就确定的吧。

从来都是第 2 种。
不知道为什么，但我感觉第一种如果要写的话，可能会写成 size_content ，而且是在 C/C++里用。

静止时省电的话，那隔了一段时间再移动容易发生瞬移吧

算法不单是时间复杂度的问题，结果是否正确也是很重要的一部分。

@matrix67 https://www.zhihu.com/question/360737017
大体就是 Nginx 作者是利用工作业余时间写的代码，老东家现在想分一杯羹。后来好像不了了之了。
一个很重要的点就是是否占用了工作时间、用了工作设备。因此如果自己写项目，最好用自己的设备、自己的许可、只在下班时间写，更重要的是看好合同。

SQL 难做的话，考虑放程序里

用爱发电

@crysislinux 以前我在初学 npm 和 python 的 pip 的时候，就有过疑问：他们要怎么解决命名冲突？为啥不参考 maven 的 pom 坐标的方式？
当时我在网上搜索的时候，得到的答案是：js 开发者倾向于简单的做法。（不记得在哪儿看到了）
我接受了这个理由，所以才会觉得 ES 官方的导入语法不太合适。

我个人感觉 JS 和 Python 是非常相近的，都是脚本语言，追求简单。npm install xxx 和 pip install xxx ，但 Python 就提供了 from xxx import xxx 的语法。

@crysislinux 但实际上不是很长。
ES 在给出模块化定义的时候，没给出推荐的形式（至少我是从没听人提起过），比如 Java 的域名反写，那确实到会是很长。

本来还以为你存了什么蓝光电影、电视剧、动漫之类的，结果还挺正常
看了看自己的，发现也用掉了 79GB 的空间，那确实有点不够用了。

@aaronlam
我也感觉这么更好，如果这么写的话，那我写完 `from './demo.js' ` IDE 就可以推导了
现在把 import 的放前面就很麻烦

js 模块的话不 export 就是私有的，这就是封装嘛，不让你关注细节

Java 有访问控制符啊，public 、protected 之类的。

Python 倒是留给导入者决定的。
但我感觉 JS 的 export 明显更好啊，看 export 部分就知道导出了啥，有哪些可用的。

自己买 License 就好了，个人买的是可以在公司里用的。但如果公司把钱补贴给你，让你买个人版是不行的。

如果是我领导不让用 IDEA 的话，那我肯定会自己买。让同事去折腾 VSCode 。
但是这部分肯定要算入成本，用于对比其它公司的薪资。
（不过就算公司买了，我估计也还会再买，详见 Nginx 作者）

之前看加拿大白嫖王一期视频就是尝试不用 Adobe
最终得出一个结论，Adobe 虽然贵，但员工的薪水更贵。

@thinkershare 完全同意，这就是我搞 Python 依赖时的最大痛点。兼容性巨差。
不光是版本问题。Python 本身说是一种“跨平台”的语言，但只限于纯 Python 的情况。实际应用中很多库都是 C/C++写的，但 C/C++不是跨平台的呀。

@ysc3839 Node.js 和 npm 是一体的嘛。

最好的方式其实是 Java Maven 的管理方式。
在整个机子上有一个中央仓库（.m2/repository ），里面按照坐标（组织、项目、版本）的方式存储着所有下载过的 jar 包，Java 项目只需要通过一个 pom.xml 引用，相关工具就会设置好 ClassPath 。两个项目依赖同一个库的不同版本也完全不用担心。

node_modules 这种放本地的做法，拉跨了点，但至少“两个项目依赖同一个库的不同版本”也还是没问题，只要你用的 Node.js 本身不是特别老。

但到了 Python ，两个项目依赖同一个库的不同版本就得创个新的虚拟环境了。

@whusnoopy
npm 没有啥虚拟空间吧，就算 cd 进对应文件夹，which npm 和 which node 的结果也是一样的。
但 python 的虚拟环境激活后，which python 结果就不一样了（虽然也是个软链接），是伪全局。

感觉 requipments.txt 比起 package.json 还差点。npm init 的时候就创建了 package.json ，使用 npm 命令安装、更新、移除依赖还会同步更改 package.json 。
而 requirements.txt 则需要手动编写，自动导出还会弄出一些隐式存在的包。

具体实现先放一边，主要看设计思路。npm 放本地的做法明显更适合工程、项目。


按理来说，全局安装也有相应的好处。就是方便共享，对于脚本程序确实很合适。
但问题是，实操下来，python 相关库的版本兼容性问题很大，甚至 python 自己的版本也很重要。常常需要创建新的虚拟环境，这种时候全局的方式就很不实用。

这是我感觉 python 拉跨的地方之一，npm 再差至少一开始也有 package.json
python 要装就全局装，没有项目级依赖，pyenv 和 conda 也只是虚拟了一个全局环境（没用过 pdm ），感觉更像 nvm

不过从另一方面来说应该又与 python 的应用场景有关，因为 python 与 C/C++深度结合
我个人 pyenv 用得少，基本都用 conda 。
像 geos 、torch 这种，其实不光是 python 的版本要管理。