就是 callkit
不过好像管得比较严

@existmoe Medis 其实是免费的，App Store 买相当于是给作者捐助
Medis 可以比较容易下载到别人做好的免费版本
如果不放心 自己用源码也可以编译一个自用

@Dvel 现在自己编译运行 iOS App 不需要付费开发者了
任何人有 xcode 就可以 只不过有效期只有 7 天 过期需要重装

@Ritr 你说的是 gyp 把
那个你只要配置一次就好了 而且任何二进制模块编译都需要 我大部分项目都有二进制模块所以就还好
不太记得 win 下是否有预编译好的模块下载 如果有的话就不用本地编译了

这个等什么时候 node 稳定支持 wasm 应该就可以彻底解决这个问题了把

不过 @king888 真的提供了一个很好的选择 https://www.npmjs.com/package/sass
这个实际上已经算是 js 版本了 不需要编译 就可以用了 就是稍微慢一些

@Ritr 为什么不友好呢 如果说 ruby 版的确实 但现在都是 c 版的了 node-sass 应该在 win 下没啥大问题

如果仅仅考虑 sass less stylus 里面挑一种 建议 sass(scss)
最成熟 而且用的人也多

less 出现的时候 比 sass 的主要优势就是 less 是 js 实现的 所以对 nodejs 比较友好 而 sass 之前是 ruby 实现的
但是现在 sass 核心使用 c/c++实现的 node 的支持也没问题了 所以 less 比 sass 的优势就没那么明显了 功能上和成熟度还不如 sass
很多流行的框架 都有 sass 源码 但 less 的比较少 用 sass 比较方便扩展和定制
(stylus 基本上不考虑了)

除此之外 postcss 也是可以的 可以单独用或者作为 sass 的补充也不错

除开这几个预处理器 还有一些 css-in-js 的实现 可以了解一下
可能灵活度会更好 而且对 component 组件化更加友好一些
但是功能和成熟度要差一些 而且选择也是眼花缭乱

由于有网站利用自动播放声音广告 现在很多浏览器都默认禁止了

@learningman 还不能是 externals 这样碰到了还是会报错
如果确定不用到可以 ignore 或者用空文件替代

那就没有别的了
除非你有快捷键冲突
或者你要剪切非文本框的文字 那么自然没部分剪切 但是会起到复制的作用

比如你在回复的时候 你选中文字 cmd+x 就肯定可以剪切
另外在右键菜单里面也会有剪切呀

不过也有情况是某些 App 里面没办法复制或者剪切的

不是吧 这么基础的问题 应该网上很容易找到解答把
Cmd+X 啊 Mac 快捷键 常用的基本上就是把 Cmd 当作 Ctrl 就可以了
除非你连 Cmd+C 和 Cmd+V 都不知道

可以的 理论上 5w 都可以充电

但是最好是关机充电 至少要睡眠的情况下
否则 如果一边用一边充 那么充的还没用的多 电池还会减少

其实原因很简单 要把 Intel 换成 AMD 也是要下很大功夫的
对苹果而已 与其花这个功夫 不如干脆用 ARM 取代算了 一步到位
而且同时也对 iPhone iPad 会有帮助 不需要再整两套硬件了

@Stain5 T2 本来就是 ARM 所以你说的 ARM + x86 现在已经是这样了 而且分担了很多底层的活
只不过 如果 x86 还在 这个 ARM CPU 还不能太强大 不然功耗吃不消
这样一来 谁还会花功夫跟着苹果把 app 从 x86 迁移到弱很多的 ARM 上面去

对于高端 mac 接着用 Intel 1-2 年就可以了
到时候 自己的 ARM CPU 应该也可以堆叠的很强大了 GPU 也可以同时发展
应该就可以彻底取代 x86 的架构了

绝对不会 相反 苹果希望把 macOS 变成 iOS 这样所有 App 就都要从 App Store 里面购买了

估计躺着看个视频还行
想干点别的需要操作的就算了 顶多点点鼠标 偶尔点下键盘

曾经半躺在床上用笔记本码代码一个多月 觉得腰比坐着的时候还疼

你这种完全躺下的就更没办法用键盘或者触摸板了 手悬着会累死的

理论上是可以的 你可以访问任何远程的文件当作本地使用 就和 ssh 一样
当然 这需要你找一个有这个功能的扩展或者自己写一个
vscode 提供了文件系统 API 只要你实现了这个 API 你连接到哪里都可以
只要你能实现这个 API 就算是远程访问一个加密 zip 文件都可以 速度嘛 就不要指望什么了

但是和 ssh remote 不一样 你没办法远程执行和调试代码

看 https://github.com/microsoft/WSL/issues/4304
里面提到所有 WSL2 的系统共用同一个虚拟机 所以 IP 一样
这点和 Docker for Win/Mac 有点像，所有 docker container 都在同一个虚拟机共享内核
再加上 Docker WSL2 的话就和 WSL2 共享一个虚拟机了

其实这样是好事 你用 docker 或者多个 WSL2 实际上只开了一个虚拟机
这样资源消耗 尤其是内存消耗 估计少了很多

@user231 你用 watch 上网干什么需要那么高的速度？
watch 为了省电 4g 速度都不敢随便跑慢 5g 耗电根本带不起吧
除非 5g 芯片有低功耗协议

watch 为了省电 一般情况下连 wifi 都不用 只用 btle 连 iPhone 来通信

@yulihao 其实你不知道的是现在的 Intel Mac 已经可以“原生”“跑”iOS 应用了 而且不是通过 CPU 指令集虚拟机
跑 iOS App 其实不需要"arm to x86" 因为 iOS App 本来就有 x86 指令集的支持

iOS Simulator 虽然是“模拟器”但是不是“ARM 虚拟机” 而是基于 x86 的虚拟 OS 层
所以在 iOS Simulator 跑的 iOS 应用就是 x86 指令集的 也就是说原理上 Apple 完全可以直接打包 x86 的代码到 ipa
只要 macOS 有 iOS 运行时就可以运行（其实就是把现在那个 iOS Simulator 包装一下就是）
或者说如果 big sur 已经有 iOS 运行时 那么就算是 Intel 的 CPU 也完全可以跑 iOS App 只要 xcode 支持编译 x86 的 ipa

你说的这些我觉得 Apple 好多年前就可以做到 只是不愿意罢了：
其实只要 Apple 愿意 那么完全可以直接把 x86 打包到 ipa 然后 macOS 下可以把 iOS Simulator 包装一下并且支持 App Store 就完成了
让 ARM Mac 直接可以跑 iOS App 我觉得就是给用户更多的理由买 ARM Mac 而已

另外就是 Catalyst 其实就是把 iOS 的运行时移植到 macOS 来原生运行 而不是通过模拟器
但是毕竟因为很多硬件特性不同所以需要一定程度上修改 iOS App 的代码来“适配”
就像 iPhone App 要适配 iPad 一样 还是有一定工作量的
而且发布也同样收到开发者和 Apple 的控制

我预测等 2 年后 所有 mac 都是 arm 之后 发布 App 就可以是“全平台”的
只要做好适配 同一份代码就可以同时发布 iPhone iPad mac 以及 watch 版 App
而那时候 最新的 macOS 可能就不再支持 Intel 的 Mac 了
这样就让 Intel Mac 用户有更新 ARM Mac 的理由

@pseudo 这个就没必要自己造轮子了
有 JsonSchema 还有 Joi
都很成熟了

JSON schema 可以算是标准了 有很多库可以使用 而且有各种应用