看了半天没搞明白这个跟 c++有关系，你是不是被 c++或者之前写 c++的人伤害过

u 盘 cv 最简单直接，在不清楚公司网络状况以及相关规定的时候，最靠谱。 其实没必要纠结，这么做的人可以是大佬，也可以是菜鸟。

@rahuahua #30 原因我没说明白我的问题。 补充下，是因为我面试的时候看到的 c++绝大多数都是 80 后，90 出头的，在这个行业内都比较资深的，所以我认为他们在很早的年代就接触了计算机，在那个年代网络不发达，传输文件其实都是很大的问题，所以当时的 u 盘、tf 卡都比较火，用这种方式来传输资料是较为通用的解决方案，那么在局域网的话，小学和大学，流行的基本上都是 win 自带的网络共享以及飞鸽传书这种方案，后面逐渐互联网发达，家宽进行降费提速，使小文件使用聊天工具发送的方案使用率逐步提升，占据了一个大头，另外一部分就是网盘的崛起。 好了，有了这些前提，那么那个年代过来的程序员应该都会接触过类似的文件传输方案，现在的场景是两个 c++的程序员在入职后，需要分享依赖 or 环境啥的（我也不清楚）我看到文件夹大小有 30 个 G ，那么在这个场景下，用了个普速的 u 盘进行 cv ，而不是用局域网传输的方案来传递文件，我很疑惑。 仅此。

@rainbowhu #31 是的，如何实现我管不着。但是占用了大量时间了，这是个迭代需求，环境搞那么久，开发时间不是被压缩了么。

搞了一下午，我感觉不是拿什么传输的问题，如果上一个人依赖没管理好我甚至觉得是正常现象。 打个比方啊，拿有包管理的 npm 打个比方吧，你再稍微想象一下 c++没有包管理,你要自己构建的依赖情况 ``` npm install https://127.0.0.1:3021/user/json1.git # 7 years ago may build with vs2005 ，like maybe node-gyp dep python2 npm install https://127.0.0.1:3023/user/json2.git # 5 years ago may build with vs2012, like node-gyp dep python3 # where is the https://127.0.0.1:3021/user/json1? # wait what the f**k with json1 and json2? vs2005? they still make you? "scripts": { "build": ..., "pre-build" : "rsync D:/foo/bar/json E:/foo/bar/json3" # windows rsync, it's really cool! you made it mo**f**ker, but where is the f**king D:/foo/bar/json? } ``` 上面这些都是有依据可循的，在 vs 或者 qt 的配置里面你可能要在各个角落里面找到它们 或者会遇到 qmake ，cmake ，xmake ，vcpkg ，canon ，bazel 甚至混用的。。。 在这里再次感谢 npm ，pip ，nuget, cargo

@nevermoreluo #34 没错没错，所以我才很疑惑，第一次与 c++的同事进行开发。 再次庆幸有 npm 、maven 、go mod 、php composer 这些依赖管理方案 hhhhh 。