PHOTONS → SAMPLES → YOUR PHOTOGRAPH 一张照片的画质，先从“光到哪里去了”说起。 画幅、光圈与快门决定可用的光子预算；像素决定空间采样；ISO 参与信号读出与亮度呈现。镜头、对焦、运动、衍射和输出尺寸，决定这些资源最后能兑现多少。 ...

HEALTHSPAN / LONG GAME ...

本文章由 ChatGPT 编写，解答了我对 “为什么我们看真人不觉得“像素爆炸”，高像素照片却会让人惊叹？”的疑问 很多人都有过这样一种体验： 面对真人时，即使距离很近，我们通常也不会产生“太清晰了”“细节爆炸了”的震撼感；但当一张高像素人像照片显示在4K屏幕上，尤其是放大观看时，却很容易让人产生一种“哇，怎么这么清楚”的冲击。 这看起来似乎有些矛盾。 毕竟现实世界的信息量显然远远高于一张照片，人眼也能感知非常丰富的细节。为什么现实中的人脸反而显得普通，而一张几千万像素的照片却能让我们觉得“超高清”？ 答案并不只是“相机像素高”，而是因为人眼、相机和大脑观看世界的方式，完全不同。 人眼并不是一块均匀的“超高像素传感器” 我们经常听到“人眼相当于几亿像素”之类的说法，但这种类比其实很容易产生误解。 人眼的清晰度并不是整个视野范围都一样高。 真正具有极高空间分辨率的区域，只集中在视网膜中央很小的一片区域——黄斑中央凹。当我们想看清某个细节时，眼球会快速转动，把目标投射到这个区域。 也就是说，我们并不是同时用“超高分辨率”观察整个世界。 实际上，眼睛每秒都会发生多次快速扫视。大脑将这些不同位置的局部高清信息不断整合，于是最终产生一种错觉： 仿佛整个视野始终都是清晰的。 因此，人眼更像是一套“高速移动的小面积高分辨率扫描系统”，而不是一块覆盖全部视野的巨大高像素CMOS。 高像素照片可以把细节放大到现实中很少出现的尺度 这是高像素照片最容易制造视觉震撼的原因。 现实生活中，当我们面对一个人的时候，通常会观看整张脸、眼神、表情和身体动作。 我们很少会把一个人的眼睛放大到占据整个视野的一半。 但照片可以。 例如一张6100万像素的人像照片，在电脑上以100%比例查看时，可能只需要双击一下，就可以让一只眼睛占据半个4K显示器。 此时你看到的东西已经完全超出了正常社交距离下的观看尺度： 睫毛根部、虹膜纹理、皮肤毛孔、汗毛、嘴唇纹路、头发丝，甚至眼球中反射出的环境细节，都可能被放大到肉眼平时几乎不会专门观察的程度。 因此，我们感受到的并不是简单的“照片比真人清楚”，而是： 照片把现实中的微小细节，放大成了宏观视觉对象。 这和拿放大镜观察皮肤非常类似。 照片是静止的，而现实世界一直在运动 真人永远不是一张静态图片。 人在呼吸，眼睛在眨动，表情在变化，头部和身体会发生轻微移动；观察者自己的头部和眼球也在持续运动。 因此，大脑不会长时间锁定某一根睫毛、某一个毛孔或者某一条皮肤纹理。 现实世界中的细节始终处于动态变化之中。 而照片完全不同。 相机把某个瞬间冻结了下来。 你可以盯着一张照片上的眼睛看10秒、30秒，甚至一分钟，并不断放大。 这种观看行为在人与人面对面交流时几乎不会发生。 于是很多平时被大脑自动忽略的微小信息，突然变成了观察重点。 静止本身，就提高了我们对细节的感知能力。 相机和后期处理还会进一步强化细节 高像素照片通常并不是“原封不动的现实”。 现代摄影系统会主动强化视觉信息。 镜头负责把高频细节投射到传感器上；传感器记录信息后，RAW软件或者相机内部算法通常还会进行锐化、降噪、局部对比度增强、色彩调整等处理。 这些操作会让物体边缘更加明确。 例如： 睫毛和皮肤之间的边界会更加清晰，头发丝之间的分离感会更强，衣服纤维和皮肤纹理的局部反差也会被增强。 这就产生了一种摄影领域经常出现的现象： 照片有时会显得“比现实更锐”。 这并不是因为照片包含的信息一定比现实更多，而是因为图像处理提高了某些细节的视觉权重。 类似于HDR照片。 HDR并不是创造了新的世界，而是把原本存在、但人眼不会同时如此强烈关注的信息集中表现出来。 照片还会主动删掉现实世界中的“干扰信息” 现实世界的信息量极其庞大。 当我们看一个人时，大脑还需要同时处理很多东西： 距离、空间关系、声音、背景、身体动作、面部表情、其他人物、环境亮度，甚至气味和触觉。 因此，视觉注意力实际上被大量信息分散。 摄影却会进行一次非常彻底的信息筛选。 摄影师通过焦段、景深、构图和光线，只保留画面中最重要的一部分。 背景可能被虚化，杂乱元素被移出画面，光线被精确控制，人物被安排在最有视觉吸引力的位置。 最终，一整个复杂世界被压缩成一个有限的矩形。 于是大脑可以把几乎全部视觉注意力集中在主体上。 这就是为什么优秀的人像照片经常比现实中的普通一瞥更具有冲击力。 它不是提供了更多世界，而是删除了大量无关世界。 为什么1080P屏幕有时反而让照片显得特别“锐”？ 这里还有一个非常有趣的现象。 假设一张照片有3600万像素，而一块1080P显示器只有大约207万像素。 当这张照片全屏显示时，相当于大量原始像素被压缩到很少的屏幕像素中。 这种过程类似于“超采样”。 轻微噪点、微小抖动、局部模糊和一些镜头缺陷，在缩小过程中会被平均掉。 但大型边缘和主要细节仍然保留。 ...

一张照片能印多大，不能只看「多少万像素」，还要同时看原始像素尺寸、画面比例、是否接受裁切，以及最终的观看距离。 本文以横向、原始 3:2 文件为例，比较 NEX-5、A7R1、A7R4 和 LUMIX S1RII 在 A2、A1 上的输出效果。 PRINT LAB 你的照片，适合印多大？ 选择相机、纸张和观看距离，立即计算实际 PPI、裁切方式与建议观看距离。 相机 NEX-5 · 14.2MP A7R1 · 36MP LUMIX S1RII · 44.3MP A7R4 · 61MP 纸张尺寸 A3 · 420 × 297 mm A2 · 594 × 420 mm A1 · 841 × 594 mm 构图方式 保持 3:2，不裁切 铺满纸张，裁切两侧 计划观看距离 30 cm 拖动以比较该距离下人眼所需的分辨率。 实际输出密度 315 PPI 近看高精细 实际成像尺寸 594 × 396 mm 保持 3:2，纸张上下各留约 12 mm 白边。 像素不易分辨的距离 约 28 cm 按普通 20/20 视力、约 1 角分的理论值估算。 ...

本文记录一台实际 Windows 11 主机的排障过程。它不是“所有 TUN 蓝屏都这样修”的万能答案；核心方法是：先读转储确认致错驱动，再只改与证据相符的一段网络链路。 结论先说 这次蓝屏并不是 Wintun 本体直接崩溃，也不是“Clash 不兼容 Windows”。两个 0xD1 minidump 都落在相同的收包路径： rt640x64.sys (Realtek RTL8125B) → NDIS → tcpip / WFP → UDP → afd rt640x64.sys 是 Realtek 2.5GbE 网卡驱动。TUN 模式会显著增加转发和 UDP 收包压力，从而触发该驱动路径中的非法内存访问。处理方式是保留 Clash、Wintun、VMware 和 Hyper-V 配置，只针对物理网卡关闭有问题的 UDP 卸载与节能特性，再重启网卡验证。 本次已实施的修复 关闭 UDP IPv4/IPv6 Checksum Offload、Green Ethernet、Gigabit Lite、Power Saving Mode、Selective Suspend；有线网络重新连通，DNS、ICMP、HTTPS 均通过复测，修改后没有产生新的 BugCheck。 说人话就是 代理开启TUN之后，网络流量变多、路径更复杂，尤其是 UDP 包。 此时的 Realtek 网卡驱动 rt640x64.sys 在 “接收网络数据” 时出了差错，把坏数据交给了 Windows 网络系统。Windows发现内核内存可能写坏，只能立刻蓝屏自保。 解决的方案：关闭了网卡里容易出问题的“硬件加速收包”和省电功能。 为什么这个方案能解决问题？ ...

仅统计台式机配件；以下为曾出现过的低价参考，用于购买前比价，不代表当前成交价。 ...

A7R4 拍照片 东西 推荐 重量约 用途 机身 A7R4 665g 主力 镜头 腾龙 28-75 F2.8 G2 540g 绝大多数场景一镜搞定 外拍灯 Godox AD200Pro II 900g 白天压太阳、夜拍、人像补光 引闪器 Godox X3-S 48g 超小，支持 TTL/HSS 灯架/三脚架 Ulanzi MT-49 790g 灯架 / 相机架 / 独脚架 柔光 60~65cm 快开柔光箱/伞 ~300–600g 人像 压重 空沙袋 ~100–200g 到现场塞矿泉水 电池 NP-FZ100 ×2 ~170g 一块机内、一块备用 小附件 备用卡、转接头、清洁布 ~100g — 整套大约 3.6～4.0kg。 S1R2 拍视频 设备 选择 重量 机身 Lumix S1R II 795g 主镜头 Sigma 28-70 F2.8 DG DN C 470g ND 67mm VND ~60–120g 无线麦 DJI Mic Mini 1TX+1RX 27.8g 常亮灯 Zhiyun MOLUS X100 385g X100电池手柄 原厂 Grip Battery 440g 灯架 Ulanzi MT-49 ~790g 柔光 X100 Mini Softbox 几百克以内 杂物 卡、电池、线、空沙袋 ~300g 整套大概 3.3～3.6kg

在 Windows PC 上跑一个小服务，把 CPU / 内存 / 网络 / GPU / 游戏 FPS 画成一张仪表盘，通过 WiFi 以 MJPEG 流推给掌机全屏显示。掌机会自己扫局域网找出所有能监控的 PC，左右键切换，Y 键转屏（支持竖屏），自己的电量也会显示在顶栏、低电量时震动。 支持三类掌机，共用同一个 PC 端服务： 掌机 系统 播放器 部署位置 Miyoo Mini Plus Onion OS ffplay /mnt/SDCARD/App/PCMonitor Powkiddy X55 等 RK3566 机器 ROCKNIX mpv /storage/roms/ports Anbernic RG35XX Pro 等 muOS ffmpeg → /dev/fb0 /mnt/mmc/MUOS/application/PC Monitor 一屏包含：CPU 总占用 / 温度 / 功耗 / 每个逻辑核心的占用与实时频率、游戏 FPS、GPU 占用 / 温度 / 功耗 / 显存、CPU 占用前三的进程、GPU 占用前三的进程、网络实时上下行与当日累计流量、内存、掌机电量、天气（当前 + 未来 3 小时 / 6 小时 / 两天的温度和天气）、以及 AI 额度（Claude / DeepSeek / MiniMax 的用量条）。 ...

神经/认知类 Alice in Wonderland Syndrome(爱丽丝梦游仙境综合征) 感觉自己或周围物体突然变大、变小、变远、变近 也可能出现时间感、空间感异常 可与偏头痛、癫痫、感染等有关 因为症状和《爱丽丝梦游仙境》里吃了蘑菇变大变小的桥段太像,病名也就顺理成章地"文学化"了 Exploding Head Syndrome(爆炸头综合征) 入睡或醒来时突然感觉脑内出现巨大的爆炸声、枪声、雷声 实际环境中并没有声音 通常不会造成脑组织损伤,更多被认为是入睡过程中脑干活动的"小故障" Cotard Syndrome(科塔尔综合征) 患者可能坚信自己已经死亡、身体不存在或内脏已经消失 属于严重的精神/神经精神症状,也被称为"行尸综合征"(Walking Corpse Syndrome) 通常与重度抑郁、精神分裂等疾病或脑损伤相关 Foreign Accent Syndrome(外国口音综合征) 脑损伤、卒中等之后,说话方式突然发生变化 听起来像出现了外国口音 实际上并不是真的学会了另一种语言,而是发音的节奏、重音模式发生了改变 Capgras Syndrome(卡普格拉综合征) 患者坚信自己身边熟悉的人(配偶、家人)已经被一个外表一模一样的"冒名者"替换 理论上认为是面孔识别与情感反应之间的神经联系被切断——“认得出脸,却唤不起熟悉感” 常见于脑损伤、痴呆或精神分裂症患者 耳科/感觉异常类 突发性耳聋(SSNHL) 通常表现为短时间内突然出现听力下降 可能伴随耳鸣、耳闷、眩晕 这是需要尽快就医的急症之一,不是适合长期观察的"小毛病" 耳鸣(Tinnitus) 没有外部声源,却听到嗡嗡声、蝉鸣、嘶嘶声等 原因非常多,从耳蜗损伤到神经系统因素都有可能,很多情况下找不到明确病因 听觉过敏(Hyperacusis) 正常环境声音被感觉成异常刺耳甚至疼痛 和普通"耳朵比较敏感"不是一回事,严重时日常生活中的关门声、餐具碰撞声都难以忍受 前庭性偏头痛(Vestibular Migraine) 可以主要表现为眩晕、空间失衡、视觉不适 甚至没有明显头痛 很容易被误认为单纯耳石症或内耳疾病,导致长期误诊 音乐性幻听(Musical Ear Syndrome) 在没有外部声源的情况下,反复听到熟悉或不熟悉的旋律、歌曲 多见于听力下降的人群,被认为是大脑在"信息缺失"时自行填补声音信号 患者通常清楚这不是真实存在的声音,与精神疾病导致的幻听不同 发作性疾病 阵发性睡病/猝倒(Narcolepsy with Cataplexy) 突然无法控制地进入睡眠 强烈情绪刺激时可能出现肌肉突然失去力量 例如大笑时膝盖突然发软 短暂性全面遗忘(Transient Global Amnesia, TGA) 突然出现严重的短期记忆障碍 不断重复询问同一个问题 通常几个小时后逐渐恢复 发作时往往意识清醒,但无法形成新的记忆 短暂性脑缺血发作(TIA) ...

这些东西我没有一个是从书上看来的，全是踩过坑之后才明白为什么不能这么写。排名不分先后，纯粹是想到哪写到哪。 1. 只给ID，标题让前端自己一个个请求 场景很常见：前端要一个文章列表，后端图省事，GET /articles 只返回一堆 id，然后美其名曰"职责分离"——标题详情是另一个接口的事，你调 GET /articles/{id} 自己拼去。 结果就是列表页一进来，控制台里刷出几十个并发请求，首屏卡成PPT。这不是设计，这是把N+1查询问题原封不动甩给了前端，还顺便多绕了一层网络延迟。列表接口该把列表页需要的字段一次性拼好返回，这不是"过度设计"，这是接口的基本职责。 2. 全表返回，不做分页 “反正数据量不大”——这句话是很多线上事故的开场白。今天不大，半年后呢？没有分页参数的接口，就是埋了一颗定时炸弹，炸的时候往往连负责人自己都忘了当初为什么这么写。哪怕现在数据只有几百条，分页也该在设计阶段就加上，代价几乎为零，省下的是未来某次大促时数据库被一个"查全部"接口打满连接池的命。 3. 自增主键直接暴露给前端 /api/order/1001、/api/order/1002……这种URL我见一次难受一次。别人改个数字就能把你家订单量、用户增长速度、甚至竞品的下单节奏摸得一清二楚，运气不好还能顺便遍历出别人的订单详情。对外暴露的标识符该用UUID或者做一层编码，自增ID留在库里自己用就好，它不欠任何人一次直接曝光。 4. 异常堆栈原样甩给前端 线上环境返回500的时候，body里直接是一段完整的Java堆栈，类名、包路径、SQL语句全在里面——这种接口调试起来是挺爽，问题是生产环境不该有这种爽。这相当于把系统架构图直接发给了任何一个愿意多点几次的人。异常该在网关或全局异常处理器那一层被拦下来，转成一句用户能看懂、攻击者看不出细节的提示，详细堆栈老老实实进日志。 5. 事务里塞一个外部HTTP调用 有一次在 @Transactional 方法里调了一个第三方短信接口，那接口偶尔抽风延迟到十几秒。事务没提交完,数据库连接和行锁全程占着不撒手，一个接口卡住,连接池被排队请求瞬间打满，整个服务跟着一起趴下。外部调用和数据库事务从来不是一路人，该放事务外面的就老老实实放外面，实在需要保证一致性，用消息队列和补偿机制去做,别指望一个事务把所有环节焊死。 6. 用GET做有副作用的操作 GET /user/delete?id=1——这种接口写出来的时候可能只是图方便,浏览器插件预加载、爬虫、CDN缓存,随便一个都可能替你把"删除"这个动作提前执行了。GET的语义是幂等和无副作用，这不是规范洁癖，是因为整条链路上一堆中间层都会按这个假设去优化和缓存你的请求。有副作用的操作，POST/DELETE该用哪个用哪个,别为了省事挑软柿子捏。 7. 返回体里带着密码字段 哪怕只是加密后的密码,哪怕前端根本用不上这个字段,只要它出现在响应体里,就是多一次泄露的机会。抓包工具随手一看,一串哈希也可能被撞库反查出来。查询用户信息的DTO,该在序列化层面就把敏感字段挡掉,而不是寄希望于前端"不会去看"。 8. 循环里一条一条操作Redis或数据库 for 循环里挨个 redis.set()、挨个 insert，数据量小的时候看不出毛病，数据量一上来，网络往返的耗时全部线性叠加，接口响应时间跟着数据量一起爆炸。批量场景该用 pipeline、批量插入，这不是性能优化的"进阶技巧"，是写批量逻辑时候就该有的默认选项。 这几条共同的毛病，其实都是同一件事：图眼前方便，把成本转嫁给了未来的自己、前端同事，或者压根不认识的用户。后端接口设计里，“能跑"和"该这么设计"从来是两件事,分清楚这两者,大概就能避开清单里一半的坑。