V2EX 2026-10-22 昨日新帖报告
1 吉列换舒适手动剃刀:刀头成本与体验对比
核心内容
楼主用吉列锋隐致护六年,感觉刀头耐久度下降:一周刮五次,约一个多月就钝,剃须有拉扯感。查资料得知吉列新款上市后,老刀头会转到越南工厂生产,只有极光系列刀头仍在美国产;极光 8 个刀头约 200 元,折合 25 元一个。
后来了解到盒刀市场份额第二的舒适,入手水次元 Pro:135 元含刀架加 5 个刀头,另花 110 元买 8 个刀头;不追新款的话,水次元 5 刀头约 10 元一个。楼主称剃须体验与锋隐致护无明显区别,耐久度待观察,性价比明显更高。
关键认知:手动剃须刀的手柄基本是白送的,真正赚钱的是刀头和剃须泡沫。
关键要点
- 锋隐致护实际约用 10 次就感觉变钝,20 次左右该换,为省钱常撑到一个多月。
- 舒适水次元 Pro 的刀头带润滑盒,会释放较多润滑液;润滑液用完后剃感如何尚不确定。
- 购买渠道:楼主在京东凑单,叠加限时立减 50 和返利后约 133 元;日常淘宝、拼多多同款约 220 元,建议等活动。
评论补充
- 有用户用吉列三层替代五层,认为差别不大但便宜很多;也有人用得力 2 元 10 片、舒适一次性剃刀(拼多多约 2 元一支)。
- 有用户称拼多多锋隐刀头约 88 元 8 个,质疑楼主 110 元偏贵;也有人反映吉列替换刀头不如刀架自带初始刀头耐用,且进口与否会在商品页标明。
- 舒适旧款创 4 纪(四层刀片)获好评;理然新出的剃须刀也有人询问使用体验,暂无结论。
原链接:关于手动剃刀,最近从吉列换成舒适了,消费降级,体验没降。回复 64 · 收藏 25
2 根管治疗后牙齿会变脆吗?是否必须做牙冠及费用经验
核心内容
根管治疗后的牙齿确实会变脆,但并非必然很快损坏。多位用户经验表明,做牙冠是保护根管牙的关键,否则容易崩裂甚至拔除。治疗本身有寿命,保护得当可用十几年甚至更久。
关键要点
- 牙齿变脆的原因:根管清除了牙髓,牙齿失去营养供给和痛觉保护;治疗需磨除部分牙体,结构强度下降。
- 牙冠的必要性:多数回复强调根管后应做牙冠或嵌体,否则咬硬物易崩裂。有用户未做牙冠,几年后牙冠裂开最终拔除,后续种植+矫正花费两万五。
- 费用参考:有用户北大口腔根管+打桩+牙冠共约7000元;另一用户预估后槽牙根管约5000元。
- 医院选择:建议去三甲或当地口碑好的公立医院。有用户在小诊所根管不到位,5-6年后出现瘘管,二次根管花费4-5千。
- 长期预期:根管牙是逐步走向拔牙的过程,日常防护可延缓;避免咬硬物,有夜磨牙习惯可配护牙套。
评论补充
部分用户根管后十年未做牙冠,但不用该牙咬硬物;也有医生认为牙齿太小无法做牙冠,仅填充。是否做牙冠需结合牙齿位置和医生评估。
原链接:根管治疗过的聊聊回复 68 · 收藏 17
3 宝塔 PHP 7.0–8.1 的 PHP2Shell 漏洞修复包及一键升级回滚脚本
核心内容
作者针对 PHP 官方披露的 PHP2Shell 漏洞(CVE-2026-109618 / CVE-2026-109619,CVSS 9.2,无需登录即可远程执行代码,影响 PHP-FPM 与 Apache mod_php),为宝塔面板用户做了一套覆盖 PHP 7.0–8.1 的修复包,开源地址为 https://github.com/Qsnh/php2shell-fixed 。
关键要点
- 补丁来源:7.4 / 8.0 / 8.1 使用 PHP 官方补丁原件;7.0–7.3 基于官方 7.4 补丁逐版本移植。
- 顺带升级:每个版本升到该分支最后一个版本(如 7.3.x → 7.3.33),一并获得历年安全修复。
- 一键脚本:下载后
build、install两条命令完成升级;自动沿用宝塔原编译参数,php.ini、FPM 配置与 redis 等扩展保持不变。 - 安全机制:安装前完整备份,任一步失败自动回滚,也可手动一条命令回滚;每个版本站点仅中断数秒。
- 测试范围:在 Ubuntu 16.04 与 CentOS 7 上按宝塔方式安装未打补丁版本,逐版本验证升级、回滚、FPM 行为,并与未打补丁版本做数千个回归测试对比。
评论补充
- 有用户询问 PHP 5.x 支持,作者随后补充了 5.4 / 5.5 / 5.6;另有用户给出第三方 5.x 补丁仓库 https://github.com/vperetti/php-cve-2026-109618-109619-backports ,作者表示原理相同,但对方只提供 patch。
- 有用户反馈宝塔官方已推送修复版本,可直接在面板更新;作者提醒 8.2 及以上无需此包,长期仍建议迁移到 PHP 8.2+。
- 限制:7.0–7.3 的移植补丁未经 PHP 官方审核,上线前应在测试环境验证。
原链接:用宝塔装了 PHP 7.x / 8.0 / 8.1 的朋友注意了!我和 AI 一起做了一套修复包,覆盖 PHP 7.0 – 8.1回复 17 · 收藏 10
4 117个智能设备接入HA:Claude写自动化与IPv6中继踩坑
核心内容
作者在成都新家接入米家 105 台设备,HA 中共 117 台设备、3800 多个实体,自动化基本由 Claude Code(Opus 5.5)按需求编写。开关、温控、阀门多为蓝牙 Mesh 2.0,网关本地执行,断网仍可开关灯阀。
关键要点
- “欢迎回家”条件复杂:需同时满足时间段、两小时内未播报、玄关空置 30 分钟、其他房间无人、灯全关、音箱未播放;书房无传感器仍是盲区。
- 设备状态不可信:海尔洗衣机筒门始终报“关”,改为检测生活阳台是否有人。
- 漏水关阀性价比最高:6 个水浸传感器加阀门控制器不到 600 元,报警后网关本地直接关总阀。
- IPv6 只有 /64:光猫无法桥接,让 J4125 直连光猫,用 odhcpd 将 RA/DHCPv6/NDP 设为 relay 中继;需光猫断电重拨生效,新设备有约十分钟慢热期,且无 NAT 需单独配置防火墙。
- 旁路由与远程:电视手动指定网关和 DNS 指向 J4125 即可看 YouTube/Netflix,需屏蔽 QUIC;无公网 IP 靠 Tailscale,自建成都 DERP。
- AI 翻车教训:曾误开中央空调 37 秒、只复刻网页“保存”一半动作导致整网告警。现规定改配置先备份、动真实设备先询问、夜间不测试、路由器只读、密码自己输。
评论补充
有回复认为“欢迎回家”和洗衣机提醒属伪需求,建议关联门锁、半小时内不重复播报,或直接洗烘一体;也有人建议直接向装维要光猫密码改桥接。另有用户用豆包写自动化、以 FRP/MQTT 做远程数据回传,或使用 ZeroTier 组网;还有人反馈开启 IPv6 会影响正常网络而放弃。
原链接:新家 117 个智能设备,自动化基本是 Claude 帮我写的,聊聊踩坑和感受回复 20 · 收藏 8
5 AWS Lightsail 全球多区域共享流量监控与自动停机部署手册
核心内容
AWS Lightsail 没有内置“流量快用完自动停机”功能,作者用 Lambda + SNS + EventBridge 自建了一套监控方案,可并发扫描全球 15 个 Lightsail 区域,按区域汇总共享流量池,并在用量超过配额 95% 时强制关停该区域全部实例、发送邮件告警。脚本在 Lambda 免费额度内运行。
关键要点
- 区域流量池计算:严格对齐计费规则,累加同区域所有实例的配额与用量(入站 + 出站)。
- 首月配额折算:当月新建实例按剩余时间比例折算可用免费配额。
- 部署步骤:先建 SNS 标准主题并完成邮件订阅确认;再建 Python 3.12+ Lambda,内存 256/512 MB、超时改为 30 秒(默认 3 秒不够);然后给执行角色加内联策略,授予
lightsail:GetInstances/GetInstance/GetInstanceMetricData/StopInstance与sns:Publish;粘贴代码并核对SNS_TOPIC_ARN;最后用 EventBridge 设rate(1 hour)或rate(15 minutes)定时触发。 - 成本控制:把 CloudWatch 日志保留期设为 7 天或 30 天。
- 删除实例的计费陷阱:停止的实例仍保留月度配额供同区域共享;月中删除跑过流量的实例会扣减区域配额,可能导致剩余机器超额,建议先关机到月底再删。
- 流量双向计费:出站与入站都计入,例如 2000GB 配额下出 500GB、入 1600GB 即已超额。
评论补充
回复仅表示收藏与感谢,未提供额外技术细节或反驳意见。
原链接:AWS Lightsail 全球多区域共享流量监控与自动停机部署手册回复 2 · 收藏 6
6 宝塔面板同步PHP漏洞修复进展:8.2至8.5及7.4/8.0/8.1已推送
核心内容
宝塔面板官方在社区同步了 PHP 漏洞修复的发布进展:PHP 官方发布修复后,宝塔因需兼容多版本系统,编译测试耗时较长。时间线为:14:47 先在社群和公众号发布临时缓解方案;21:40 监控到官方修复后开始编译测试;23:05 推送 8.2 版本修复;23:20 推送仍在维护的 8.2、8.3、8.4、8.5 四个版本;23:45 公众号再次提醒升级;次日 01:38 发布 7.4、8.0、8.1 的补丁打包修复。
关键要点
- 官方仅提供 7.4、8.0、8.1 的修复补丁,宝塔需自行打包测试,因此这三个版本发布较晚。
- 官方提醒尽快升级,社区中已发现疑似入侵利用案例,不要心存侥幸。
- 建议迁移到官方仍在安全维护周期内的版本,旧版本停止维护后难以及时获得补丁。
- 官方判断 AI 加速了漏洞发现与利用,旧版本风险进一步上升。
评论补充
多数回复确认已更新并认可响应速度。实际痛点集中在更老版本:多位用户询问 5.x、5.6、7.3 及以下版本是否有补丁,有人建议用 AI 辅助自行编译;也有回复提到第三方提供了 php7.0~7.3 的补丁包(https://github.com/Qsnh/php2shell-fixed),并询问官方能否同步修复。另有用户询问 aapanel 的更新计划。
原链接:和大家同步一下宝塔面板关于 PHP 漏洞的发布进展回复 30 · 收藏 5
7 开源管线:Blender合成数据微调DINOv2还原视频动作到非人形3D模型
核心内容
作者开源了一条从生图到骨骼动画的全自动管线,重点解决非人形 3D 模型的自动绑骨与视频动作还原。流程为:Tripo3D 生成基础模型 → TokenRig 自动绑骨蒙皮 → 在 Blender 中用双视角与随机姿势渲染 3,000 个动作样本作为合成训练集 → 基于 DINOv2 微调视觉小模型,输入渲染图与关节坐标标注 → MiniMax H3 生成目标动作视频 → 小模型逐帧推理提取关节坐标与深度 → 解算映射回模型,重建 3D 骨骼动画。
关键要点
- 用 Blender 合成数据绕开非人形动作标注稀缺的问题,是整条管线的关键。
- 训练与推理代码已开源:GrinZero/open-game-studio 的 monster 包(https://github.com/GrinZero/open-game-studio/tree/main/packages/monster)。
- 算力来自 Gemini Ultra 附赠的 Colab 额度。
- 作者自评效果“勉强可用”,动作大形已无问题,下一步接入 DeepSeek 4.1 Flash 配合同坐标叠图与逐帧评分工具去抖。
评论补充
有回复建议在关节坐标推理与骨骼解算之间加一层轻量滤波(如 1Euro Filter 或卡尔曼滤波),按关节点设置不同截止频率;并建议大模型逐帧修正采用“关键帧 + 异常阈值触发”,避免长镜头下 token 开销累积。作者回应滤波已先做,逐帧修正比预想复杂。另有用户询问 2D Spine 方案,作者表示未涉及。
原链接:[开源] 从生图到骨骼动画全自动:用 Blender 合成数据微调 DINOv2,把视频动作还原到非人形 3D 模型上回复 7 · 收藏 9
8 BT 公网资源冷清后:PT、网盘与离线下载的取舍
核心内容
主帖的疑问是:熟悉的 BT 搜索站几乎找不到做种资源,活跃的却是需要邀请的私人论坛。评论区的共识是,公网 BT 并未消失,而是冷门资源难以保种,下载渠道逐渐转向 PT、网盘离线或在线媒体库。
关键要点
- 公网 BT 仍可用:热门资源下载体验尚可,冷门资源容易死种;有稳定粉丝团体的老种(如 vcb-s、fitgirl)体验较好。
- PT 的核心差异:底层仍是 BitTorrent 协议,但通过上传约束和小组供种提高保种稳定性,代价是需要邀请与持续做种。
- 替代路径:网盘离线可救部分死种,再拖回本地;也可用 Emby 类在线媒体直接观看。
- 冷门资源的实操:有回复建议热门用 qBittorrent,冷门用迅雷离线或挂 NAS 慢下,同时搜索网盘分享。
- 公网 BT 衰落的原因:迅雷吸血、家宽上传限速与 PCDN 限制、版权打击,以及流媒体便利性削弱了部分盗版需求。
评论补充
有用户认为 IPFS 理论上更科学,但因生态薄弱、引导节点集中、隐私与法律风险等原因未能替代 BT。也有用户指出 PT 资源未必齐全,且邀请制存在门槛;另有回复愿意发放 MT 邀请,但要求保种。
> 注意:以上为社区经验,具体站点可用性与运营商策略需自行核实。
原链接:现在 BT 下载全都变成私域了吗?回复 29 · 收藏 3
9 FluxDown v0.6.0 插件系统:JS 沙箱、权限分级与跨端界面
核心内容
开源多协议下载器 FluxDown(AGPL-3.0,Rust 引擎,支持 HTTP/BT/HLS/DASH/FTP/eD2K,含桌面、NAS Web、Android/iOS)在 v0.6.0 发布插件系统。插件是一个含 manifest.json 与 JS 脚本的文件夹,打包为 .fxplug,可提供链接解析、下载后处理、请求改写、站点登录、订阅源、界面扩展、浏览器嗅探规则与页面脚本等能力。
关键要点
- 跨端界面:插件界面用 JSX 编写,由宿主渲染,同一份代码可显示在 GPUI 桌面端与 NAS Web 端;内置标题、表格、表单、进度条等组件。
- 安全设计:脚本运行在 QuickJS 沙箱,默认仅有
flux.*基础能力;创建任务、拦截下载、登录、页面脚本等需单独授权,更新新增权限会再次询问;授权分「标准/较高权限/完全信任」三档,并有审计日志与连续 3 次超时或超内存的自动禁用熔断。 - 失败策略:解析失败直接报错(fail-closed),不会退回下载原始页面。
- 开发方式:SDK 已发布 npm,可用
npx fluxdown-plugin-sdk create创建项目,npm run dev热构建、npm run pack打包;manifest 校验器与应用共用同一套规则。 - 文档与仓库:开发文档见 https://fluxdown.com/docs/zh/plugins/overview/ ,插件索引仓为 https://github.com/zerx-lab/fluxdown-plugin-index 。
评论补充
作者确认移动端暂不支持插件,因能力过多,后续可能实现部分功能;另有用户反馈 issue 822,作者表示将测试修复。
原链接:给开源下载器 FluxDown 做了一套插件系统:网页解析、拦截下载、自定义界面,桌面和 Web 端通用回复 4 · 收藏 3
10 广州前端被优化:绩效与N+1仲裁取证要点
核心内容
广州一名前端员工在合同到期前一个月面临被优化,公司只愿按“基本月薪×(N+1)”赔偿,并拖欠一年绩效(每月为基本月薪的25%,按季度发放)。他想追讨绩效,并要求N+1按平均工资计算。评论区的共识是:N+1基数应按离职前12个月平均薪资(含奖金、提成)计算;绩效能否追回,关键看劳动合同或员工手册是否明确约定“必然发放”,以及能否举证。
关键要点
- 绩效举证是核心:若合同写明“每月绩效=基本月薪×25%”,仲裁支持的可能性较大;若手册写的是“视评分/项目成果发放”,则难以主张。往年稳定发放记录、同组他人已发、季度评分记录都可作为证据。
- 书面异议别超期:立即以书面形式(私人邮箱或EMS/挂号信,普通快递法律效力低)向公司提出绩效异议,避免超过追诉时效。
- 拖到满三年:合同签订日满三年后再解除,赔偿可能多约2个月工资;期间正常上下班,不主动表达离职意愿。
- 谈话录音、签字谨慎:所有沟通录音;对不认可的签字文件先反馈协商,不轻易签。
- 评估仲裁成本:先到当地仲裁庭了解排期,可能需一两年;机会成本高则拿N+1尽快找新工作。
评论补充
有回复提醒:年底双薪即使写在offer上,也可能被认定为奖励性质而不受支持;广州主体是皮包公司、存在混合用工,需注意主体注销风险。也有回复建议花少量咨询费多问几位律师,并指出调查取证申请在实践中常被仲裁院回绝,证据主要靠自己。楼主则强调金额达数万元,不应因耗时而放弃。
原链接:关于离职赔偿索要,哪位大兄弟有经验的指导一下回复 14 · 收藏 2
11 跨境电商多账号网络:固定住宅IP与指纹浏览器隔离方案
核心内容
做 TikTok、Facebook、Reddit 等跨境电商运营,核心问题不是“机场还是自建”,而是 IP 固定、干净、与账号一一对应。主帖担心机场多 IP 切换导致封号,评论区的共识是:切换比 IP 脏更容易触发风控。
关键要点
- 机场:多人共用出口,IP 信誉不可控,节点可能自动切换。若使用,至少锁死节点,关闭自动选择/负载均衡。
- 自建 VPS:机房 IP(数据中心 ASN)稳定但容易被平台标记,不一定“干净”。
- 住宅 IP:常见做法是 VPS/机场做链路,落地用静态住宅 IP;轮换住宅 IP 对养号反而不利。
- 环境隔离:一个账号配一个指纹浏览器环境、固定一个 IP,不跨账号共用。
- 上线前自检:检查 IP 的 ASN 类型(住宅/机房)、DNS 与 WebRTC 是否泄漏、时区和语言是否与 IP 所在地一致。
评论补充
有回复建议预算有限时用“固定落地的 VPS + 静态住宅 IP + 指纹浏览器”,比买贵机场更划算;也有人认为紫鸟、战斧等成熟方案更省事,精力应放在运营而非每月一两百元成本上。主帖作者最终认同:前置代理自建或机场只需速度稳定,关键在指纹浏览器与优质住宅 IP。
注意:以上为经验性建议,平台风控规则未在讨论中给出官方依据,需自行验证。
原链接:做跨境电商,代理是购买机场还是自建?需要住宅 ip 吗?回复 11 · 收藏 0
12 CVE-2026-91403:JDK 全版本受 eMudhra 证书影响及临时缓解
核心内容
CVE-2026-91403 与 eMudhra(印度 CA)的 8 张中级 CA 证书有关。发帖者指出,公告中列出的版本只是“已测试发现有问题”的版本,并不代表其他 JDK 不受影响;按此推断,几乎所有 JDK 都存在风险。目前修复版本尚未发布,只能按公告做临时缓解。
关键要点
- 缓解方式:从 OpenJDK 公告页下载对应平台的
blocked.certs,备份后替换$JAVA_HOME/lib/security/blocked.certs。 - JDK 8 特例:文件名是
blacklisted.certs,路径相同。 - 被拉黑的是 8 张 eMudhra 中级 CA 证书。
- 发帖者确认 Oracle JDK 与 OpenJDK 均受影响。
- 参考链接:https://openjdk.org/groups/vulnerability/advisories/2026-10-21 (
blocked.certs下载页)、https://www.oracle.com/security-alerts/alert-cve-2026-91403.html 。
评论补充
有回复认为,这本质上是 CA 证书信任问题,与 Go 等语言遇到的是同类问题;另有回复列出 Google/Go、Mozilla、Perl、Red Hat、Python 等也分配了相关编号,并称影响范围可能覆盖所有互联网设施。也有回复质疑:对服务端而言,这类漏洞难以被实际利用,是否算“重大漏洞”值得商榷。
注意:上述影响范围与严重性判断来自发帖者和评论者,尚未经独立验证,建议以官方公告为准。
原链接:Java 重大漏洞 CVE-2026-91403回复 14 · 收藏 3
13 PingCAP TiDB Cloud 被曝 10.6TB 数据外泄,官方否认客户数据受影响
核心内容
据安全公司 Fulcrum 披露,PingCAP 生产控制平面疑似被持续导出数据:累计 10.6 TB、约 490 万个文件,连续 88 次(每 6 小时一次)导出未被检测。涉及约 50 个 GCP 存储桶、单仓 5.338 亿行的 BigQuery 数据、180,046 个租户组织、403,262 个独立邮箱、115,308 个客户明文 API 密钥(其中 42,612 个仍有效)、2064 万条客户 SQL 语句、1.02 亿次网关连接记录、503 万个客户服务器 IP,以及 413 个私有源码仓库等。
关键要点
- 攻击者据称利用仓库中提交的 GCP 服务账号密钥与 Azure 服务主体,建立控制面数据库的复制通道。
- PingCAP 官方安全公告称,外部事件响应公司未发现攻击者在被审查系统中执行命令或维持持久访问的证据,也没有证据表明存储在 TiDB 中的数据受到影响。
- 评论补充认为,泄露的主要是 TiDB 内部经营数据,数据库本身及客户数据库不受影响。
- 双方说法存在明显分歧,泄露范围与影响仍需以官方取证结论为准。
评论补充
有回复指出,这类事件并非个例,建议使用密钥扫描与周期性轮换工具(如评论提到的 keyrotate.sh),排查环境、系统和仓库中的 API key 与密钥并定期失效。
原链接:PingCap TiDB 生产环境 10.6 TB 数据泄露回复 5 · 收藏 3