Redis 不是要尽量避免 bigkey 的吗，还专门存 Redis ？

继承过户成本最低，不急的话公示三个月，就几十块印花税，急的话继承公证也要一两万
当然一般不会正好碰到继承，直系亲属过户也只能走买卖，实测亲母子之间走买卖过户，如果价格太低也会被要求核定，这个房管局不管，由同在政务中心的税务局核定，而且不同区域房产底价税务局不公开
当然也可以选择赠予过户，那后续再出手很大概率要交 20%个税，各地政策不同，建议去政务中心问清楚
如果只是直系亲属之间只是求个保障的话，两人签个房价等额的借款合同，然后用房产证做抵押登记，登记费几百块，求保险的话可以先过户个最低份额 1%到 5%，这样房产既单人无法过户也私下抵押也影响不大(抵押登记优先受偿)，然后慢慢等继承

keepass2 + 直接存储在坚果云免费的 webdav 上

@junkk Go 只是木有类似 Django 、spring 全家桶之类前后端一把梭的框架，但就开发个后台 api ，一般就是十几个接收 http 请求再返回纯 json 的接口，整个项目随便用什么语言开发都不过几百行代码，用大而全的框架，绝大多数功能用不着还严重影响性能，随便配置下框架可能都不止这点代码
而 Go 都是精简框架，只提供了基础的路由、响应、中间件等，很适合 api 开发啊，比如 fiber 之类，因为用了 fasthttp 非常适合密集的小请求，比如物联网设备，偶 2 核 8G 的云服务器支持近 60 万设备几分钟定时上报存时序，外加十几处大屏缓存显示，QPS 平均 2 万高峰期过 5 万服务器还空得很，换 spring 全家桶的话服务器预算加个 0 估计都悬
当然如果预计 QPS 不过千又不需要保密源码的 API 服务，FastAPI 一把梭就是了

大多数梯子都不太稳定，偶尔需要手动操作换源。建议还是装个旁路由，单独指定需要外网的设备走旁路由
新手最便宜的方法是买个 t1 、n1 之类的盒子刷旁路由固件，足够用了，nas 虚拟机或找个能刷 iStoreOS 的盒子，iStoreOS 向导自带旁路由模式，设置方便

看标题还以为是嵌入式硬件，那弄块合宙 9.9 包邮的 esp32c3 开发板，新手自己看 arduino 入门再转 idf
没想到是 BIOS 开发，建议如果前端耽误了学习进度，都很难靠自学跟上的话，BIOS 就算了吧，两者差距跟小学二年级直接考高数差不多

单纯写 API 的话，偶最初选的 Python FastAPI ，专业写 API 的框架，确实自动类型验证和生成接口文档方便不少，但实测性能实在孱弱，同配置下都是异步读写 Redis ，FastAPI 压测 QPS 仅 4 千，而 Go Fiber QPS 有 5 万，而且不少库比如 TDengine 官方 Python 连接器不支持异步，性能更差
果断中途换 Go Fiber ，大项目新手可能会学很久，但如果只写 API 也就接收几个参数，读写下缓存和数据库再返回 JSON 而已，Go 新手熟悉下文档三天内肯定能写 API ，压测性能爆表，实测 Fiber 代码量也没比 FastAPI 大多少，就是 err 处理繁琐点，没选 gin 是因为据说路由不好用

现在西数企业级的 SN640 7.68T 也才 1K5 出头吧，国行 5 年保，写入寿命无敌，就是速度慢点
达墨 16T 2K 左右很奇怪咩？再贵的话难卖吧

呃，居然被当成疑似内部人士了，别太敏感，偶只是路过吃瓜码农
只是正好最近接触过类似援助，都是劳动者先申请仲裁但不给材料，仲裁委会先通知补正，继续不理的话就会因通知补正仍不齐备下达不予受理裁定，拿着这份裁定就能直接诉讼了，大概 7~10 天吧，不用耗 2 个月，不少律所都这么干
另外，就算审判长同意因涉及个人隐私不公开，但案件基础信息比如原被告姓名和案由还是会上传的，只是裁判文书内容一栏显示为不公开，去裁判文书网搜索下名字，名下有案件的案由是劳动争议，基本就懂了，你可以去裁判文书网自己看看，这种涉及隐私不公开的案子离婚纠纷和抚养纠纷里比较多，虽然正文隐藏但名字和案由都能看到的
PS：至于偶说“如果不占理还闹大了”，个人认为仲裁无法调解闹到法庭就算闹大了，实务中很多都是劳动者的诉求合法但不合情理，用人单位捏着鼻子认栽再回去找法务补漏，当然也有用人单位自己作死的，反正闹到法院大概率都是劳动者赢，祝你成功吧

本地律所接劳动仲裁，一般都是仅提交仲裁但不给材料，这样很快就会因材料不全被驳回，然后走诉讼，一般耗时一周左右，用不着 60 天
诉讼确实可以主动向审判长要求不公开直播审理，文书也不提交裁判文书网，但审判长不一定会同意，毕竟用人单位大概率会反对
而且就是文书不公开也防不了背调吧，从社保记录里找到上几家单位打电话一问不就曝光了，虽然仲裁记录不可查，但如果不占理还闹大了大概率瞒不住吧

参考下通过宿主机的防火墙控制本机 Docker 容器网络的方案，可能会有帮助
https://github.com/chaifeng/ufw-docker

SSH 暴露在 22 端口还是 443 端口，安全上没区别啊
一般尽量不直接暴露 SSH 端口，需要通过跳板机或者 VPN ，至少防火墙设置下只允许指定 IP 段连接 SSH 端口，只是家用不太现实
校园网只要 SSH 仅用证书登录问题也不大，想保险的话，自己签发个证书，本机装 Stunnel 客户端，将指定端口的 SSH 数据 TLS 加密后发往学校服务器 443 端口，学校服务器装 Stunnel 服务端，将 443 端口接收到的数据解密后转发到本机 SSH 端口，相当于对整个 SSH 连接进行了透明转发+TLS 加密，只要自签发的证书没丢，基本也没多少风险

没理解，既然 A 的防火墙只允许 B 的 IP 入站，B 的 IP 对外泄露需要更换的话，还得手动修改 A 的防火墙配置啊
至于配置转发的话，手动配置 IP-Tables 容易出错，建议通过 UFW 的 IP 伪装功能来配置，透明转发或者指定端口转发都行，没接触过这么奇怪的需求，理论上应该可行吧
开个玩笑，如果 B 单纯做透明转发的话，干脆 B 装个 OpenWrt ，然后将 A 的 IP 设置为 DMZ 主机，完全映射端口不就是了