想到一句歌词
谁说难道毁灭就不需要勇气
但是当你没有想明白后续的情况下 还是建议先维持原状
避免一时冲动造成后面无法挽回
具体为如果开发觉得做不下去 预期胡思乱想不如先去接触你所说的 技术支持 销售 外卖
哪怕是利用周末也好 做一段时间 觉得比现在强
那换一个工作也是义无反顾 要是直接裸转 就怕到时候不适应会有更多的焦虑
当然还是只是一些不成熟的建议 供参考

@Gct012 可以 但是好像你想要 ABC 顺序执行 那为什么不直接在外面开多线程呢
即 ThreadUtils.excutor.excute(list ->
functionA(list.get(i));
functionB(resultA);
functionC(resultC);
)
同时我注意到 resultList 是一个 http 请求 那是不是这个 list 请求一遍就可以了?
List resultList = HttpRequest.post(url).body(list.get(i));
//下面是原来的 for 循环的代替
resultList.stream.paralla.map(currentList ->{
ThreadUtiles.excutor.excute
.....
}

)
以上都是伪代码哈 只是提供一个思路

function ABC 是否可以直接用多线程来执行? 如果可以的话就可以节约很多资源
或者直接用 parallelStream 来代替 for 循环处理 也可以直接并行处理
但是具体要看对数据的操作方式吧 如果没有时序要求可以考虑
还有我也是个菜鸡 如果说的不对望后面大佬指出

那天天叫着土区的岂不是凉了? 但是我怎么感觉这个公告指的是原有价格经过汇率换算后不准确的问题呢
即 99 刀->648 元在新的定价下变成 99 刀->690 元

@TUTU2014 更换电池是会跑检测的 不过我倒是觉得不必太过担心
因为无非就是倒是后跑了检测
没有测出来->直接换新
测试出来了->放弃维修 没有损失
顺便刚刚还想了个歪门邪道 如果跑出来有问题 第三方换个喇叭再...
不过估计喇叭这种小部件不会加密 毕竟价格不高

帮你找了下 国行设备的话主要部件还有第二年保修不知道你的设备是否符合
但是 18 的话估计很难了 这样的话维修就只有其他损坏的选项 要 4k 多
建议如果电池最大容量已经到 80%左右了 直接去换电池吧 799 直接换整机

@loveour 是的 raid5 比 raid0 可靠
可能是我没表述清楚 我想说的是
组 raid1/raid5/raid6 就认为数据万事大吉 不需要备份的情况
其中除了 raid1 稍微好一点以外 剩下的根本无法替代定期备份
以及网盘的可靠性是比自己搞要高得多 这毋庸置疑
但是一方面本地速度访问还是要快一些(至少在网络环境比较糟糕的地方)
另一方面数据存在本地还是多一层隐私的 只能说和云盘比起来各有优劣吧 hhh

省电+docker -> NUC/Mac mini
额外有硬盘存储需求 -> 外接硬盘柜 如果最大 8 盘位都满足不了你 可以上 hub
一个设备满足->成品 nas 根据预算量力而行
没具体预算只能建议到这个地步了

Nas 9.....980+????
我有一个备用方案 但是因为最近涉及到搬家 就还没有实际验证
具体就是用一个柜子放起来 目前看好的选项大概是机柜或者宜家最普通的储物柜
前者好看结实 但是可能不隔音
宜家柜子便宜但是不好看(你也不想把一堆灯都遮挡住吧?)
至于噪音目前想的是用内置 6 面吸音棉解决 这个对普通柜子还好 但是机房那种开放式的柜子可能不好不知
至于灰尘和温度 可以在柜子里面统一设置风道+过滤物来解决
当然还是那句话 目前没有实际实施 不知道这样还有多少坑....

这里说一条暴论 至少我是这么认为的 并去遵守的 只提供参考 不构成实际建议
我觉得人活在世上 首先的要务是自己
不是说每个人都应该自私 都竭力去占便宜
但是当你想做的 和别人想让你做的冲突的时候
第一个问题应该是 他的要求你能否接受 如果不能且不对他人造成影响(这里是指除了你们之外的第三方) 那你有拒绝的权力
对于这个问题 就是你可以说 你想让我 XXX 但是我也可以说 我不想 所以我拒绝
至于你说什么 你怎么这样 你是不是 XXX? 白养了之类的
一律算作道德绑架
why? 所以按照你的逻辑 你养育我就是一场交换吗?
不是 那上面的话就是无效的
如果是 那也可以 定一个界限吧 做到了我就当我偿还完了 后面就休想用道德绑架我
不要说是父母了 哪怕是朋友的恩情都是不可否认的 也值得我们感恩
但是这不是你或者你们道德绑架我的理由 我也不接受用这种手段让我就范
如果我想这么做 那自然无所谓
如果我不想 除非你用道理说服我 (如行动不便需要有人协助 或者哪方面有困难需要帮助之类的) 否则
我拒绝
还是那句话 以上均为暴论 有骂名我可以担着 可以反思 我也愿意去改进 这个暴论本来就不成熟 也不正确 他只是可以帮助我真切地感受到 我还活着 而不是被道德裹挟到无法呼吸
(逃

喜闻乐见 终于遇到一个新鲜的例子来支撑 个人没事不要做 raid raid 不能保护数据 应该备份 这样的观点了
帮忙搜索了一下 可以参考下
https://www.ucmadscientist.com/almost-lost-it-all-again/
当然这个教程极大概率和你遇到的问题不相同 但是可以试一下排查思路 去看看日志 看能不能导出数据 然后重置吧
此外 如果无法导出(注意是真的没有办法 因为越折腾数据越危险)
可以把硬盘单独卸下来 参照这个用 linux 尝试恢复
https://kb.synology.cn/zh-cn/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC

@monkeyzsf 首先如果已经讨论过了 为何不贴出链接供大家学习呢?
其次无论是初始的分析帖还是后续的"据信"2 次解释贴均与我无任何利益关系 该贴的分析言之有理 我认为这是一个可能的方向故提出 何为引战?
其次我们讨论的是为何流畅 手机更新与否或许与漏洞利用强关联 和该 app 流畅是否有联系呢? 您嘴上说着技术优化 您的回答我未看见除 漏洞可以被手机更新修复 以外任何有建设性的观点 试问是谁在引战

我记得我上一台手机是 18 年买的首发 iPhone8p 5k
一直用到 22 年 换手机是因为家人有需求换了 否则再坚持至少 2 年感觉不是问题
以上

@Vveeb 嘿 您再往下看 直接创建一个系统进程 您以为的冷启动 实际上人家是系统级权限+后台作弊(逃

这时候就要祭出这个了
https://www.v2ex.com/t/920460#reply6

会 Linux 命令的话可以 这里特指 mdadm 命令
注意操作之前要先停止对盘的读写 以防发生意外 以及即便是用命令 也可能损坏数据 还是建议优先楼上的拷贝数据到新盘方案
具体思路为
basic 为一个特殊的 raid 结构 即一个盘的 raid
先插入一个空白盘+要替换的盘
启动后先将空白盘用 synology 工具格式化
然后制作文件系统
(或者用图形界面直接新建一个 basic 盘)
然后用 mdadm --grow /dev/md/mirror --add /dev/sdc1 --raid-devices=2
等 raid 拷贝数据结束后 (cat /proc/mdstat 可以查看进度)
用 mdadm /dev/md/mirror --fail /dev/sdc1 --remove /dev/sdc1 来移除原来的旧盘
就行了