“笔记本被拿去的那一刻，在限制的时间内没有输入正确的口令，系统自动删除数据，且不可恢复”——能做到。
结果：故意阻挠公安机关调查取证，恶意破坏证据，罪加一等。

@fengleiyidao 大部分是因为不会用 jb ，还有一部分是需求太简单用不到 jb 的功能

只要创建一个专门用于远程编辑的空项目，然后配置好 sftp 链接，以后需要的时候就打开这个项目，点工具-部署-浏览远程主机，然后就可以在已保存的服务器中选择，打开查看文件数，双击文件自动下载进入编辑模式，编辑好可以直接上传覆盖

有，内置的部署工具即可
https://www.jetbrains.com/help/idea/editing-individual-files-on-remote-hosts.html

果子这不是为人 S 钱多的分担钱多花不出去的痛苦吗
觉得贵说明你不是果子的目标用户
反正对我来说是白送都嫌没地方放的玩意儿

端转发 kvm 的 22 端口到宿主机不就行了

深度截图有这个功能

```不过他也承认，现阶段并没有将 ARM64 设备用于任何真正的工作，只是将其用于版本测试、启动以及现版本的发布。
```
linus 目前只在 MBA 上看看代码回回邮件，做点测试发布工作，说白了就是当成个便携的上网本在用，真要主力开发还有段距离。
前段时间我也试了 Asahi Linux ，问题还是挺多的，受限于 arm64 linux 的生态问题，很多工具还是没有或者运行出错。
我装 Asahi 也是因为平时主力开发有 Linux 台式，便携也有 Linux 的轻薄本，公司配的 MBA 不装 Linux 的话对我来说基本只能吃灰。目前现状就是上上网写写文档问题不大，写点脚本语言也没问题，但是涉及到编译的工作，大概率还是不行的，所以折腾了两天没啥劲，又把这系统刷掉了

@debuggerx app 名:《前端谁最屌》

@FantasticLBP 既然什么技术栈都可以写，那可以在一个 app 里同事用不同技术栈写同样的测试案例，最好是可以一个屏幕里分屏对比不同技术栈，让整天吵来吵去的人可以直观得对比，到底哪种技术做的 app 流畅性能好，开发方便代码量少
一个人能力有限，可以开源出来让各个技术栈的高手优化，最终得到一个有说服力的技术栈对比 demo

如果只是因为担心硬盘挂而选择使用虚拟机，个人觉得大可不必，物理机一样可以做定时备份

@wdwwtzy 我觉得没什么亮点就是优点，上面有解释，我喜欢这个 Angel3 这个 dart 的后端框架就是因为觉得它和 Express 很像，写起来有熟悉的感觉

@janus77 可以看看我这两个 controller 实现逻辑的写法是不是“简洁”？
https://github.com/debuggerx01/dde_gesture_manager/blob/dev/api/lib/src/routes/controllers/scheme_controllers.dart
https://github.com/debuggerx01/dde_gesture_manager/blob/dev/api/lib/src/routes/controllers/auth_controllers.dart

@zqlcrow 应该是在说我对吧~
可以看我自己的回顾总结：
https://www.debuggerx.com/2020/12/29/these-years-about-flutter-and-me/

```
2017 年 12 月:
为公司规划中的新项目调研跨平台方案可行性，在尝试了包括 React Native 、ionic 、Cordova 、Cordova 、Weex 等在内几乎当时所有流行的方案之后，竟没有一个能够让人满意的。直到发现了当时还在 alpha 版的 Flutter ，被其优秀的开发体验、精妙的架构设计和惊艳的流畅度表现所折服，于是开始正式研究该框架。
```

一个佐证是，我写的 flutter 的 json 解析工具的初版提交日期：
https://github.com/debuggerx01/JSONFormat4Flutter/commit/e234c5bc77c84017a77fe79a969e9b24d6eb4710

@montaro2017 MPFlutter 是可以用写 flutter 的方式开发小程序，但是几乎没法复用代码，要支持小程序，就只能用最基础的 widgets 库和 MPFlutter 提供的组件，flutter 内置的 Material 和 Cupertino ，以及大量社区的库都没法用了，所以几乎必然是小程序一套代码，其他前端平台一套代码，这样的话我还不如用其他更成熟的方案去写小程序，反正都是重做。
虽然我觉得 Flueer/dart 很好，但也不无脑吹它可以做任何事，我的观点一直是根据需求选合适的方案。开发小程序我个人大概率会用 Taro ，对这个方案也还算熟悉，开发体验也还可以

5 年+的 flutter 开发经验，也用 dart 开发过后端，我人为的 dart 的优点：
1. 支持 AOT 编译，产物可以几乎无依赖的直接部署，这点可以对标 go 的部署方便，比 JS 、TS 、python 等需要运行时依赖的语言方便很多，比如我一个项目里 dart 后端只需要这样一个 Dockerfile：
https://github.com/debuggerx01/dde_gesture_manager/blob/dev/api/Dockerfile
就可以得到一个 10 几 MB 的镜像，服务跑起来内存占用也才 50MB 不到，可以说非常方便了，资源消耗也够低

2. 语法常规，可以说几乎没有非常特立独行的概念和语法，几乎所有语法特性都是在其他语言中经过验证的，结果就是 dart 学起来曲线平滑、写起来非常舒服、代码表达能力和组织能力也相当不错，尤其是在有其他语言如 Java 系列、js 系列、Python 、Swift 经验以后。举几个例子：
a.语法级的异步支持，不像原始的 java 一样像做点啥都需要开线程，结果各种多线程 bug ，开发时的心智负担低很多，性能还不差
b. 单继承+mixin ，即提高了代码复用性和组织能力，又避免了多继承带来的各种问题
c. 强类型，尤其是全面转向健全空安全之后，类型系统可以说达到了一个相当均衡的状态，该有的特性基本都有（抽象类、泛型等，GO ？），正常使用情况下很少出现包括 NPE 在内的类型错误(JS ？)，而且类型代码书写的成本也不高，很少需要复杂的类型处理(TS ？)

3. 还算不错的工具链和 IDE 支持，pub 依赖管理比 npm 等好用不少，dart format 格式化可以避免多人合作风格不一导致的代码差异和冲突，dart compile 就可以很方便的将源码编译成 js/可执行二进制程序 /jit 快照 /aot 快照，jetbrains 全系和 vsc 都可以安装 dart 插件获得相当稳定的 IDE 支持（ Swift/XCode ？）,还有内置的基于 web 和 ws 的 DevTools ，分析程序的运行性能也很方便

4. 几乎没有平台依赖，平台支持足够广泛，而且几乎都可以支持大部分功能，不像某些语言，号称跨平台，实际上是和某一平台和生态强绑定，其他平台只有“core”支持（ C#、Swift ？），发展前景高下立判

5. 生态已经足够繁荣。这点可能很多人会不认同，会去和 Java 和 js 比，但是就我而言，想做的东西几乎都可以用它做了，例如：
a. 前端，不用说，肯定就是 flutter ，这个方案可以覆盖除了小程序之外几乎所有的前端需求。可能有些人觉得 flutter 不行、不好用，我只能说可能是有些人和有些特定项目不适合 flutter 而已，或者是单纯的能力不足
b. 后端，简单的需求用 dart 内置的 io 库就能解决差不多，复杂的我个人推荐“Angel3”这个框架，总的来说比较接近 Express.js ，后端开发常见的功能也都支持了，只要花点时间看看源码（很简单）完全可以满足一般的后端开发需求
c. 工具脚本，这点得益于 dart 既可以解释执行也可以编译执行，就非常适合一些简单的工具开发。我在自己电脑上就会用 dart 写一些脚本，随时可以方便的修改使用；编译后可以直接放到手机的 Ternux 或者机顶盒路由器上运行，部署使用方便
d. 各种三方库，基本都可以在 pub.dev 中找到，很多时候并不需要像很多以为的需要造很多轮子。印象比较深刻的是在移植一个 python 的算法到 dart 时，科学计算和信号处理这种相对冷门的库都已经有实现： https://www.debuggerx.com/2021/02/18/qrs-detector-for-flutter-in-dart/

感觉正相反，感觉这玩意只会让初级开发的学习能力下降，使中高级开发变更稀缺

1. flutter 在很多情况下是非常好的技术方案，从这个角度可以说它确实是“趋势”。
2 没有一种方案会是所有场景下的最优解，或者说那句老话，没有银弹，从这个角度说，没有任何一种技术可以称作“趋势”。
3 不建议拿所谓“大厂”的选择和产品来评价方案和技术，很多情况下他们的选择对我们没有任何参考意义。
4 新、酷、过时、流行，个人觉得这些词评价技术挺无聊的，flutter 刚出来还是 alpha 版的时候，我就看好它，因为看到这个方案的发展潜力和能够解决的痛点；相反很多新出的热门技术，虽然有些吸引人的噱头，但是本质却没有很大的进步，或者本身存在很大很难解决的短板，那我就觉得没必要投资精力去学习。

感觉这个“远程开发环境”没啥必要，对开发体验没啥提升，可能还不如搞 CI 跑自动化啥的。