对第一次从 touch ID 转用 Face ID 的我来说，Face ID 确实要比 touch ID 方便很多，各种授权操作不需要特地挪拇指放在 home 键上也不用考虑手指是否脏污。

我 iPhone 12 到手后仅在开机激活阶段录入人脸，除了需要基本正视手机才能解锁外，识别率相当高，正常使用也没有增加额外的解锁步骤，然后搭配辅助里的“注视”系列功能，相当舒服。在日常使用中，我个人除了视频和手游需要横屏外，绝大部分时间都是正握手机，所以不能正视手机解锁的情况相当少。（我能想到的需要的情况是视频临时暂停，触发手机自动息屏，然后又不方便挪动手机正视？但我个人习惯是手动锁屏的）

正打算考虑购入一个立式无线充电器放办公室桌子，有消息来了通知不显示内容，需要视线“注视”手机才会触发解锁显示内容。这个应用场景在 touch ID 下就只能不厌其烦地去摸 home 键（前提还要屏幕被点亮）

至于识别解锁后还需要上拉才能进入，这个从使用逻辑上是合理的，毕竟有些时候只想看看时间和通知内容，总不能亮屏就直接自动进入桌面吧？ touch ID 也是需要按电源键再摸 home 键或者直接按 home 点亮自动识别解锁的，解锁上仅有的优势是手机抬起亮屏摸 home 解锁。

至于背部指纹解锁，和正面 Home 解锁逻辑一致，只是单纯贴合了手势方便握持解锁。相信我，当你想把手机放桌上桌上使用但又不得不频繁拿起摸背部解锁，尤其还设置了超时息屏的时候，你就会对背部指纹解锁深恶痛绝

在我看来，touch ID 除了能避免面部遮挡识别解锁、亮屏时摸键解锁的优势，不需要正视手机外，face ID 比 touch ID 更便捷合理（一不小心点了支付光速识别，钱就直接转出去了，哈哈哈哈哈）

PS：听说面部遮挡问题，face ID 还能通过 AI 学习人脸变化，以此提高口罩遮蔽等情况下的识别率，不知道真假

这个功能叫便捷访问，全面屏下手势是屏幕底部白条处往下滑，但是建议还是改成背部三击

因为在大多数 APP 内底部都是功能导航栏，手指比较大的经常在下滑的时候误触切换功能页

@EyreYoung 我也知道好看，但我买不起

不退了，昨天被网友影响了，现在仔细想了想手机是拿来用的，不是拿来看的，颜色随意

反正后面我自己都会加个带支架的壳用，这蓝色基本看不到

@mooyo 感谢解答。到时候再看看，真的受不了再考虑换绿色

12 128G 蓝，16 日抢购，预计 23 日送达
但是我已经想退换了

@leeggco 但是订单已经准备发货状态，不知道咋退…… ……

完了，入手的 12 蓝色，借贴问一下，拆封后想换颜色，只能去预约去直营店换了吗？

0202 年了，还是不支持
导致我现在蓝牙键盘连 iPad，压根没法打双拼，因为自带的输入法没有自然码方案

@zhoudaiyu 其实都差不多，主要是防漏消息提醒的话，小米手环续航确实舒服

这个六位 PIN 码式解锁是有这个问题，但自从升级 13.3 后强制长密码，用自带输入法输入的密码就没这问题

老实说吧，你是贴吧过来的还是知乎过来的

@NSDont
NextCloud 毕竟基于 PHP，通过上传或同步客户端处理大量文件到数据库和自身程序里是很吃力的（除非专门进行调优），官方也是知道自己的情况，所以服务端提供了一系列 occ 的指令操作，其中有一个 files:scan 是专门处理文件扫描的，你可以去服务端手册看一下

```
sudo -u www-data php occ files:scan --help
Usage:
files:scan [-p|--path="..."] [-q|--quiet] [-v|vv|vvv --verbose] [--all]
[user_id1] ... [user_idN]
Arguments:
user_id will rescan all files of the given user(s)
Options:
--path limit rescan to the user/path given
--all will rescan all files of all known users
--quiet suppress any output
--verbose files and directories being processed are shown
additionally during scanning
--unscanned scan only previously unscanned files
```

用其他手段传输好后直接扫描添加到数据库和 NextCloud 中，效率会高很多，最好的是物理手段，移动硬盘之类的。另外针对大量小文件，我建议在本地打包后放到 NextCloud 对应的路径后进行解压，再使用 occ files:scan 扫描添加

多半是跑满了路由器缓存或者 CPU

我家的 surface book 以及其他的移动设备通过 WNDR4300 5GHz WiFi 接入，读写 NAS 的 smb 共享文件夹的时候大文件读写会时不时断流，要等个 30s 左右才能恢复继续，其他有线接入的设备没出现这种情况

后来换了 R8000 后就没出现这个问题了

@ddup 快 5 个月了，在调试中发现这是 Windows Docker 和 MySQL for Windows 之间的互访问题，我将数据库转移到 Docker 内部的 MariaDB 容器后，NextCloud 一切功能正常，效率还挺不错的