不行吧，应该是 AI 读入的量比较有限，我本来也是抱着这种期望去用的，结果挺失望的。所以就没再用 cursor 了，帮不上忙

我个人觉得是冗余了，所以我不用。
类似地，我也很少在后面加 data 或 info

https://www.v2ex.com/t/1099810
49 年入国军啊

另外说一点达芬奇设计比较麻烦的地方，就是达芬奇内部存储媒体文件路径时应该用的都是绝对路径，而不是相对路径

有的，或者说就是这样。
达芬奇在剪辑时时不会去动源文件的，所以你的所有操作都是对工程文件的操作。另外你说的“临时副本视频（压缩、低存储文件）”那玩意儿叫做代理文件，主要是为了减少剪辑用电脑的压力的，你电脑性能强也可以不用。

我记得达芬奇甚至可以支持多人在线协同工作，不过好像有很大的限制。当然我只是听说，没用过。

我也是喜欢装软件，因为这样每个设备走不走代理比较可控。
但全局翻也是需要的，比如 Nvidia Shield 、Steam Deck 、Quest 3 、PlayStation Portal 这些设备如果不用路由器翻墙的话就用不了


另外，软路由本质是个路由器。
比如我家是 ac+ap 方案，所以软路由对我来说真的就是个不带 wifi 的路由器罢了，而且还比传统路由更好用。

现在用的是 r4s ，在那之前用的是 TL-R473G AC 路由一体机（没扔，还在用 AP 功能）。
后者的管理功能比前者差多了，比如没有 ipv6 、不能用 UU 加速器当然也不能全局翻。

期末项目而已，大不了明年重修

我 2016 年 1w 左右买的 6700k+1070 现在咸鱼价格估计能卖个 1500 左右吧
你这个东西我感觉顶多值几百块

NAS 空间太大了，不拍浪费

@importmeta 我试了一下，静态导入的话，用 Web Worker 引入的依赖似乎和普通引入的依赖没啥差别。
动态导入的话，代码分割需要加点选项。

此时 App.vue 打的包（ index-sqhKDG2-.js ）是 57.98kB 。
如果引入了 lodash ，那么：
此时增长到了 131.21kB ，大了 73.23kB ，说明是打到一起的。
使用 Worker 不引入 lodash：
worker 大小 0.32kB 。
如果是 Worker 引入了 lodash ，那么：
worker 变成了 72.39kB ，增长了 72.07kB 。
所以静态导入上是没什么区别。

不过如果是动态导入，那么 App.vue：
Worker：
不过加了点选项后好像就没问题了：

我主要是没搞懂你想要的效果是什么样的，如果你在 worker 里需要静态引入依赖，那自然会打包成一个 js 文件啊，这点无论是不是 worker 都一样。至于注释的话，似乎保留的只有版权信息，这好像是工具有意为之的。

另外，我的选择是直接使用阿里或腾讯的 CDN 服务，比如我些照片的图床用的就是。

为啥

额，说实话，一时之间我没想到难点在哪里
要不你直接把你的二开的原项目地址发出来看看，然后大家教你怎么改，这样比较方便

没办法，openai 目前还是最强的
换句话说：还能离咋地

看看我的
https://wexcdn.com/img/Snipaste_2024-12-20_23-34-12.png
整个 dist 文件夹只有 1.8M ，当然项目本身也不是很复杂

我的是 Vite6+Vue3+Element Plus ，采用了按需引入
每个包都挺小的，gzip 后更小
最占空间的应该是 ECharts ，我没做按需引入

另外我还找了另一个 React+Ant Design 的项目 Hooks Admin Pro ，这是他的打包结果：
https://wexcdn.com/img/Snipaste_2024-12-20_23-48-30.png
也才 7.1M

我觉得你的 tree shaking 还是有问题，而且我实在很好奇你用 Web Worker 都干啥了，计算量这么大吗？


另外：
1 、你应该不是 SSR 吧，要不要考虑 SSR 一下，首屏加载时间更低
2 、Antd 比较适合于中后台或者管理平台吧
3 、试试 CDN ，那玩意儿网速很快
4 、带宽也不用那么省吧，毕竟你是按带宽算钱
5 、你是 ECS 还是轻量应用服务器？

不如直接买个 switch

作为一个 Javaer ，其实没怎么想过这个问题。Java 在向后兼容方面做的比较好。某些脚本语言在这点上就做得相当垃圾。（ Node.js 和 Python ）

Java versions are expected to be binary backwards-compatible. For example, JDK 8 can run code compiled by JDK 7 or JDK 6. It is common to see applications leverage this backwards compatibility by using components built by different Java version.
所以如果我是个类库的作者，我会在编写 Java 库时尽量用低的版本。比如做的挺好的 Netty 4 就支持 Java 6 。

而作为使用者，只要你使用 8 以上，你就可以尽量用新的类库版本。

而且吧，Java 需要编译，如果接口变了或没了，那你直接编译就通不过。所以你很快就知道能不能用。如果不能用，那降个大版本基本也就能用了。


不过实际并没有那么完美，比如 nashron 引擎就被移除了。javax 的现在要注意下改成 jakarta ，万恶的 Oracle 。

微软的 rdp ，国区 app store 没有，要去美区下