zsh2517

凭印象写了几个可能会踩的坑

1. 严格禁止复制 AI 内容（包括回复）
2. 内容自己不能删除，修改有很大的限制
3. 推广内容发到推广节点（像是这种推自己的产品的，每个节点都有，多看看特点，我也不太好总结，总体来说如果项目偏小范围、非盈利，可能在程序员/技术/创意等节点的更多），希望做大/商业化，往往会发在推广
4. 回复不支持 markdown ，可以去 /go/sandbox 测试怎么放图片
5. V2EX 并不是很鼓励无意义水贴，发帖/评论是一个扣除论坛虚拟货币的操作（当然，通常够用）。参考 https://v2ex.com/balance
6. 楼中楼不完善，所以一般回复是直接 @seeksky 或者 “@seeksky #2 （楼层）”来明确回复哪条消息。由于 5+6 ，你会看到有些人会在一条评论里，同时回复很多人

敏感词是不是有点多。随便输入了几次就撞上了 [测试] 、 [IS]

@darksheep9527 #10 对，我的思路是基于这样一个前提：大部分纯自用/分享亲友的网站和应用，并不会有什么真正的复杂的关系型/非关系型数据，并且依赖专门的数据库才能使用。通常情况下，每个人的数据是独立的，不太会有跨用户的查询。这种情况下每个用户一个大的数据文档（如 JSON ）用来实现跨设备同步数据就够了。

基于此，对每个用户的数据进行打包同步，或者是封装一个通用的存储接口，然后后面写的所有的应用使用同一个后端进行数据同步。虽然还是要有一个服务器，有一个后端。但是第二个应用开始，同步的负担基本上是零了

顺着这个思路，也可以采用比如 #7 提到的 cf workers （或其他云函数）开发摆脱对服务器的依赖；#11 提到的 OneDrive 、#14 提到的 git （或者其他网盘/s3/webdav 等）前端直连的服务直接存储数据

我之前想过的几个方式

1. BaaS 平台，比如 firebase/supabase
2. 写个插件同步 localStorage/indexedDB 等前端存储
3. 思路参考 2 ，但是不走 localstorage ，而是实现一个轻量的（或者也许现在已经有成品） kv 存储/文档查询 api ，并包装成类似于 storage API 的操作。这样多个前端可以用一个后端提供服务（因为本质上是应用业务无关的存储和查询服务）
4. 导入导出 JSON
5. 前端读写前端能读写的存储服务（自用场景不需要说凭据一定要对用户隐藏，直连对象存储、webdav 等存储服务就可以）

@zsh2517 严重的 bug 倒是没遇到过，但确实会有时不时的比如卡顿掉帧等情况。以及重度使用也挺热的

以及经常遇到网络很卡的情况，但是这个不排除我附近的运营商信号问题 / 大流量卡的优先级较低

（因为我没对比过其他品牌手机，所以这个只是主观感受，不作为对比）

目前 15u ，之前用过 10s, 红米 k20p 和 k60 ，以及小米平板 5 和手环 4 、8 NFC 版。

手机没换其他品牌主要俩原因，一个是米家生态（换别的要切默认语音助手以及可能没那么系统级的集成），一个是云服务的照片不想整理。

hyperos3 确实感觉不咋好用，最近直观感受并能总结下来的问题

1. 新相册 app 难用
2. 桌面现在不显示所有页的切换了（我桌面比较乱，一共 15 页，以前可以直接点最后一页的引导圆点，现在只能一页一页翻过去）。搜索功能也没那么好用，动画有些不太衔接
3. “小爱同学，打开所有闹钟”，似乎只能打开 11 个左右，而且不是连续的
4. 1password 经常出不来，只能切到应用复制密码
5. 很多应用（包括系统应用）限制小窗
6. 信号我不确定咋样，但是应该算不上特别好的那一档

---

互联的话，手环没啥额外感受，手机/平板之间互传还行（新一些的系统，同一账号不受 10min 自动关闭限制），但是没电脑所以我还是 localsend 用的多。

手机投平板体验还可以，手机打开 Wi-Fi 的情况下，全程可以平板操作不用开手机，支持音频传输。

和苹果生态的结合我不太了解，据说做的还行，但我都是用 localsend 和 scrcpy 的

@yuheCai 应该就是为了抽象吧