我觉得主要是纯客户端渲染、静态预渲染和服务端渲染三个方式的取舍，怎么根据合适的场景去扬长避短。纯客户端渲染对服务端压力最低，但是数据 API 就要暴露出去、首帧渲染压力大。静态预渲染性能好、资源要求低，但是不灵活。服务端渲染性能好、灵活，但服务端压力大。

比如对于 header footer 这样的组件，它本身不怎么变，更新受开发者控制，预渲染 html 肯定是最好的。对于需要隐藏 API 实现且与用户相关的组件，就不得不选择服务端渲染。对于重客户端型组件，不太要求首帧性能的就选客户端渲染。所以按组件/岛屿区分渲染策略就变成大家共同的选择了。在这个思路上感觉目前还是 astro 想得最清楚，什么 server islands 、live content collections 都加上了，可惜在静态预渲染的灵活性上做的还是不够好，部分依赖 On-demand ISR 的场景得不到第一方支持

首先现在立式消毒柜（非商用）卖不动，商家已经放弃在这个产品上卷了。嵌入式消毒柜功能太鸡肋了，洗碗机就能顺手干掉消毒柜的活。所以购买选择上 洗碗机 > 嵌入式消毒柜 > 立式消毒柜。
然后是关于热风烘干的问题，因为烘干之后水并不会消失，他只是增加了柜内湿度，最终还是要被排到环境中，因为洗碗机本来就要排水，烘干的冷凝水排出方面就有天生的优势，比如西门子的洗碗机就用沸石来吸水蒸汽，在下一个洗碗周期把水排走。普通的洗碗机有两种模式，一种是外循环蒸发，水蒸汽直接排到外部空气中。但外部湿度高怎么维持内部湿度一直低就是个问题，所以有些厂家就开卷巡航模式（ 48 小时内每隔 1 小时烘干 10 分钟这种）。高级点的就用内循环排水，类似除湿机压缩机的原理，把水蒸汽冷凝然后排出，这样的好处是可以完全封闭整个柜体，防止进蟑螂或者虫子，但是成本就高了很多。康宝就有消毒柜在卷这个方向。

https://yueying-docs.effirst.com/yueying-intro.html
看起来像是这玩意插入的 meta 标签。简单看了下，UC 出的

@WangLiCha 实际上如果是单纯的 flex 布局（即使包含 wrap ）直接 flex 排就可以了，拖拽也可以正常工作，只不过由于不定宽高，要自己处理动画变形问题

你的要求 dnd-kit 都可以满足
1. 跨容器拖拽排序官方有 examples ，其实就是定义多个 container ，共享 draggable element ，如果需要的是从源容器复制的效果，则需要源容器内的 draggable element 在被 drop 后重新渲染（通过修改 key 或 id ），这样被拖走后他会在原地重新生成一个，或在拖拽开始/拖到可放置区域时重新生成一个新的 key 以破坏和源容器中的元素的对应关系

2. 限制特定交换顺序：真正的交换是否成功 是看渲染的结果，也就是说 dnd-kit 在拖拽完成的事件里你是否调用 arraymove 等帮助方法让列表数据改变，如果没有改变，那么拖拽就没有成功，列表顺序也不变

3. 每个标签有点击事件：可以通过 sensors 实现只监听某些地方的 pointer 事件，也可以通过监听 onPointerDown 事件来变相监听 onClick ，通过监听延迟来确定是移动还是点击（因为开启了 pointerSensor 后无法监听到 onClick ）

4. flex 不定宽排序：官网有例子，至于拖拽时可能的变形问题，可以通过动态渲染一个 drop item placeholder 实现，即保存一个自定义的 dragoverlay 数据，在元素可以被放置到某个位置但元素还处在被用户鼠标抓住时，插入此 dragoverlay 对应的元素到预测的位置，展现为一个半透明的占位，可以保证布局不变形

我目前遇到的 dnd-kit 较难做到的是多列瀑布流布局下的自由拖拽，拖拽可以实现，但是很难保证容器内不变形

目前（截止 2024.1.10 ） react 还没有真正生产可用的 keep-alive 方案

替代选择：
1. react@experimental 中提供的 unstable_Offscreen ，要求 React 使用 experimental 版本
2. 基于 Suspense 实现的 keep-alive ，比如极简代码实现的 react-freeze ，要求 React 17+
3. 其他介入 React 渲染流程的 hack 实现，比如你已经搜到的

结合路由的方式基本都是手动劫持 Outlet 组件的渲染，使之可以不被 unmount ，转而使用一个新的属性比如 mode 控制子路由组件是否渲染

淘宝敏匠开窗器。非广告，DIY 过一个 90 度旋转开门器正常运行了 2 年。
优点：24V 无刷电机，可以自己 DIY 主控板接，也可以用他们做好的（只能接入米家），同时支持手动和电动操作；
缺点：丑，只能外置，要在门上打钉子。手动推拉需要用力以抵抗无刷电机的阻力。

配合 webpackJsonP 的类似实现，例如重度使用此功能的 webpack5 module federation 可以实现运行时 dynamic import 进相关的 js 代码文件块（加密后），在 service-worker 层挂一个劫持逻辑做解密，或许具有可操作性？编译时要多做一步加密 jsbundle 的操作

目前实践下来最简单的方法是给需要权限的 dom 挂上 data-permission-id （你喜欢的名字），然后在整个 app 顶层用 mutationObserver 集中处理权限并按需隐藏所有的权限 dom ，既实现了框架无关也做到了动态化控制权限无需发布前端代码

其实还有魅族和 OPPO 的一些手机，安卓版本已经到了 9.0 和 X ，而他们系统内置的 webview 的 Chrome 版本还是 55 、60 ，在 sentry 上可以看到大量这些低版本报的兼容性错误

接上面，西红柿我四天之内吃了 9 个，因为我本来就喝茶，绿茶每天起步三杯，抗生素我大概四天内口服了 0.5g 的头孢克肟，感觉对症状无明显缓解作用

没有好办法，我小刀喇嗓子喇了四天，吃布洛芬片剂可以短暂把小刀换成石子，利多卡因气雾剂有效，但是维持时间太短了，半小时就疼回来了，也不敢太频繁地用。自制高渗盐溶液润嗓子也可以缓解一些，凉水效果更明显。今天稍微好转了一些，这玩意太折磨人了

还没经历装修，先对 LZ 表示羡慕，不过在改造过程中遇到的问题想到几个：

1. 厨房、卫生间预留的插座太少。因为强电设备很多，全部实现机械电源通断智能化需要的智能插座又很占地方；
2. HomeLab 控制中心（包含 NAS 、路由、主 AP ，光猫、AIO 服务器）还是很难决定位置（要兼顾散热），以及 UPS 的服务范围（是服务器、安防设备、还是全部智能设备）；
3. 灯的开关盒一定要预留零线进盒，因为现在单火线的智能开关仍然很难解决鬼火问题；
4. 如果要做智能窗帘、窗户、门，应该在哪里预留电源端子，如何保证 esp32 的弱鸡 Wi-Fi 稳定性
5. 弱电设备太多，交流转直流电源几乎每个弱电设备都要加一个，占的体积又大，发热又比较严重。如果全屋可以走一个 24V 弱电线路或许是更好的选择？（但是损耗可能也不小）

为了提高按钮的识别率一般还会搞个导电橡胶保证和电容触摸按钮的贴合

任何导体触屏都可识别--应该是你的手拿着导体测的吧？所以关键是改变触摸按钮对 GND 的电容量，用继电器 /MOS 管 /三极管切换串联电容 or 断开，或者改变电容大小随便你，注意做好电容对地放电就好了

homekit 前段时间服务域名换成了 akadns.net ，网上的 apple-list 都不包含这个域，可能需要在 openclash 确认下对应的连接情况