Posts

一句话结论 纳指100 从 10 月 13 日的 30569.48 回落到 10 月 15 日的 29935.59，跌回 30000 关口下方。现在的问题不是趋势坏了，而是支撑这轮上涨的两个前提——低成本资金、AI 叙事无摩擦——同时开始松动。 短期我偏向高位宽幅震荡（约 28500–31000）；中期方向不取决于「AI 是不是泡沫」，而取决于两个可验证的变量：加息是否真的止步、AI 资本开支能否继续上修并兑现。 下面这张图是纳斯达克100（NDX）的实时走势（打开页面时现取，不是静态快照）： 行情加载中… 一、先定位：我们现在站在哪 指标 数值 含义 纳指100（NDX100） 29935.59 已跌破 30000 整数关 近期高点 30569.48（10-13） 距高点约 -2.1% 纳指综合 26713.03 距 10-06 历史新高 -3.2%，年内 +14.9% 10 年期美债收益率 5.100% 30 年期曾触及 5.53%，2004 年以来最高 联邦基金利率 3.75%–4.00% 9 月 16 日加息 25bp，2023 年 7 月以来首次 通胀 PCE 3.7% / 核心 3.4% 高于预期，黏性没有解除 纳指100 动态市盈率 约 29–30 倍（PB 约 9.5 倍） PE 分位不高，但 PB 分位已明显偏高 黄金 / 原油 / 美元指数 4208 / 95 / 101.8 黄金创新高、油价高企 一句话概括坐标：指数还在高位、回撤很浅，但它的两个前提都已经松动了。 ...

一句话总结 10 月 6 日纳指收于 27599.89 点，创历史新高；到 10 月 15 日收于 26713.03 点，7 个交易日回撤约 -3.2%。回撤幅度不算深，但过程剧烈——期间出现过单日 -1.88% 的杀跌，也出现过“开盘跌 1.4%、尾盘翻红”的深 V。 下面这张图是纳斯达克100（NDX）的实时走势（打开页面时现取，不是文章里的静态快照；正文里的点位均为纳指综合口径）： 行情加载中… 节奏：先冲高，再连跌 日期 纳指综合收盘 备注 10-02 27190.86 +319.27 10-05 27477.31 +286.45 10-06 27599.89 历史新高（收盘） 10-07 27538.69 -61.20 10-14 26692.87 -1.88% 10-15 26713.03 +0.08%，盘中 26308.85 → 26754.02 同期，纳斯达克 100 指数（NDX）从 10 月 13 日的 30569.48 回落到 10 月 15 日的 29935.59，跌回 30000 整数关下方，两天回撤约 -2.1%——比综合指数更“贵”，也更脆弱。 ...

核心矛盾：盈利向上，利率也向上 当前纳指的多空分歧，本质是两股相反方向的力： 向上的力：AI 相关资本开支仍在加速，半导体与 AI 硬件链的盈利兑现度高。机构对 2026 年美股的盈利增速预期普遍在两位数。 向下的力：美联储 9 月重启加息（3.75%–4.00%），CPI 同比 +3.7% 未见明显回落，“利率更高更久”压制估值；同时 AI 板块的集中度与涨幅已接近历史极值。 下面三个变量，决定了未来一两个月纳指的重心往哪边偏。 先看纳指 100 的实时走势，心里有个位置感： 行情加载中… 变量一：10 月 27–28 日 FOMC 9 月已加息 25bp，点阵图显示年内“或再加一次”。 但最新非农数据降温后，市场对 10 月再加息的概率明显回落（CME FedWatch 口径一度降到两成以下），“按兵不动”成为主流预期。 真正的看点不是加不加，而是措辞：若声明强调“通胀黏性、保留进一步加息选项”，成长股承压；若强调“数据依赖、进入观察期”，风险偏好可能修复。 变量二：三季报与 AI 资本开支 财报季刚开局。市场想确认的核心是：AI 的资本开支能不能继续转化为收入与利润。 要盯的不是“超预期几个点”，而是指引：云厂商 capex 上修还是下修，直接决定半导体与 AI 硬件链的景气叙事。 若“卖铲人”（算力、存储、网络）继续上修指引，指数的分子端就有支撑；反之，估值端会先杀。 变量三：估值与集中度 有卖方测算，纳指动态市盈率近期回到 约 29 倍，低于 2023–2024 年约 33 倍的高点——这是“还不算典型泡沫”的核心论据。 但另一面：过去一年纳斯达克 100 中表现最好的 10 只股票平均上涨约 784%，已超过 2000 年互联网泡沫见顶前一年的水平。涨的宽度极窄。 机构目标价一览（仅供参照） 标的 机构 目标 / 区间 纳斯达克 100 PrimeXBT 2026 基准区间 28125–31861，年末约 30200 纳斯达克 100 Kalshi 预测市场 2026 年末约 30000 标普 500 华尔街 13 家大行 7100–8000（中位数约 7650） 标普 500 UBS 上调至 8100 美股整体 贝莱德（Q4 展望） 继续超配，聚焦 AI“瓶颈环节” 这些多是年初或季初给出的目标，指数已涨过一轮，参考价值在于共识区间，而不是精确点位。 ...

争论为什么突然升温 10 月以来，“AI 泡沫临近破裂”的讨论快速升温：英伟达自高点回撤约 5.8%，纳指从 10 月 6 日的历史新高回落约 3%；同时有卖方策略师公开警示——美股与全球市场的偏离度，已超过 2000 年互联网泡沫前夕的水平。 到底是“健康的估值消化”，还是“泡沫见顶”？先把两边论据摆清楚。 空方：三个论据 涨幅极端。过去一年纳斯达克 100 表现最好的 10 只股票平均上涨 约 784%，高于 2000 年 3 月见顶前一年的 622%。这是“历史级”的集中度。 市场在变窄。指数创新高，但上涨高度依赖少数 AI 龙头；龙头一回调，指数立刻失去支撑——10 月这轮回撤就是例子。 利率不再帮忙。美联储 9 月重启加息，通胀（CPI +3.7%）黏性仍在，“靠估值扩张推动上涨”的空间被压缩。 多方：三个反驳 这次的利润是真的。2000 年的“互联网公司”大多没有盈利；这轮 AI 龙头有实打实的现金流，云与算力的订单可见性较高。 估值没到 2000 年的水平。有卖方测算，纳指动态市盈率约 29 倍，低于 2023–2024 年约 33 倍的高点，更不用说 2000 年的极端读数。 资本开支仍在加速。主要云厂商的 AI 资本开支指引整体仍在走高，AI 相关收入兑现度较高。 一张对照表 维度 2000 年 2026 年（当前） 领涨股涨幅（前一年） 约 +622%（NDX 前十） 约 +784%（NDX 前十） 盈利基础 多数公司无盈利 龙头现金流强劲 估值水平 极端 NDX 动态 PE 约 29x 利率环境 加息周期末段 加息周期刚重启（3.75%–4.00%） 集中度 高 更高 怎么用这两个视角 判断“是不是泡沫”本身没有太大意义——有意义的是：如果是，什么时候破；如果不是，回调到哪里可以接。 ...

背景 手头有一台 4核4G 的轻量云服务器（Debian 13），想搭一个纯静态的技术博客。要求很简单：低资源占用、HTTPS、自动续期证书、页脚挂备案号。 方案选型 服务器上已经装了 1Panel 面板和 Docker 版 OpenResty，所以不再额外安装 Nginx，直接复用现有的 OpenResty 容器做反向代理和静态文件服务。静态博客不需要数据库、不需要 PHP，资源占用几乎为零。 Web 服务：复用 1Panel 的 OpenResty（Docker 容器，宿主机目录挂载进容器） 证书：acme.sh 申请 Let’s Encrypt 证书，HTTP-01 验证，自动续期 站点文件：纯 HTML/CSS，放 /opt/1panel/www/sites/域名/index/ 关键配置 站点配置放在 /opt/1panel/www/conf.d/ 下，这个目录被挂载到容器内 /usr/local/openresty/nginx/conf/conf.d/，主配置会自动 include 它： server { listen 80; server_name example.com www.example.com; # 保留 ACME 验证路径，续期时要用 location ~ /.well-known/acme-challenge { allow all; root /www/sites/example.com/index; } # 其余请求全部跳转 HTTPS location / { return 301 https://example.com$request_uri; } } server { listen 443 ssl; http2 on; server_name example.com www.example.com; root /www/sites/example.com/index; ssl_certificate /usr/local/openresty/nginx/conf/ssl/example/fullchain.pem; ssl_certificate_key /usr/local/openresty/nginx/conf/ssl/example/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; } 证书自动续期 acme.sh 安装证书时通过 --reloadcmd 指定续期后的重载命令，之后完全无需人工干预： ...

现象 一个长驻的后端服务运行三四天后内存从 200MB 涨到 1.8GB，最终被 OOM Killer 杀掉。重启后一切正常，然后周而复始。 排查过程 第一步：确认是泄漏还是缓存 先看监控曲线。如果内存是"锯齿状"（涨上去又掉下来）多半是缓存策略问题；如果是"楼梯状"只涨不跌，基本就是泄漏。我们的曲线是典型的楼梯状，确认泄漏。 第二步：抓内存快照对比 在服务运行 1 小时和 24 小时分别抓堆快照，diff 对比对象数量的增长： # 运行 1 小时 jmap -dump:live,format=b,file=heap1.hprof <pid> # 运行 24 小时 jmap -dump:live,format=b,file=heap2.hprof <pid> 用 MAT 打开两个快照对比，发现 EventListenerRegistry 里的监听器对象 24 小时增长了 4 万多个——每个都持有外部对象的引用。 第三步：定位到代码 查看注册监听器的调用点，发现问题代码： // 每次请求都会 new 一个监听器注册进去，但从不注销 public void handle(Request req) { bus.subscribe(new MetricsListener(req.getSessionId()), req.getTopic()); ... } 事件总线是全局单例，监听器以强引用形式存在，请求结束后监听器及其持有的 SessionId 等对象永远无法被回收。 修复方案 短期：把强引用订阅改成弱引用（WeakReference 包装），对象无其他引用时可被回收 长期：明确订阅生命周期，请求结束时在 finally 里注销： Listener l = new MetricsListener(req.getSessionId()); bus.subscribe(l, req.getTopic()); try { ... } finally { bus.unsubscribe(l, req.getTopic()); } 经验总结 “只注册、不注销"是内存泄漏最常见的形态之一，事件总线、定时任务、回调注册都要检查配对的注销逻辑 泄漏排查的关键是两个时间点的快照对比，而不是盯着单个快照看 上线前用压测工具模拟持续请求流，几小时内就能暴露这类问题，不用等线上跑四天

背景 订单列表接口在数据量上来后 P99 响应达到 800ms，用户明显感知卡顿。目标：压到 100ms 以内，不升级硬件。 第一步：慢查询定位（800ms → 300ms） 开启慢查询日志，发现列表页的统计子查询没走索引： EXPLAIN SELECT o.*, (SELECT COUNT(*) FROM order_item i WHERE i.order_id = o.id) AS item_count FROM orders o WHERE o.user_id = ? ORDER BY created_at DESC LIMIT 20; order_item.order_id 没有索引，子查询对每行订单做全表扫描。加上索引后接口降到 300ms。 第一刀永远先看慢查询日志。大部分"接口慢"的本质是"SQL 慢"。 第二步：消灭 N+1 查询（300ms → 120ms） ORM 的懒加载在序列化时触发了 N+1：列表 20 条订单，每条又单独查一次用户信息和商品快照，一次请求实际执行了 40+ 条 SQL。改成批量查询 + 内存组装： orders = orderRepo.findByUser(userId, 20); userMap = userRepo.findByIds(orders.map(o => o.userId)); itemMap = itemRepo.findByOrderIds(orders.map(o => o.id)); // 内存里组装，总共 3 条 SQL 第三步：缓存热点数据（120ms → 80ms） 用户信息、商品快照这类读多写少的数据加 Redis 缓存，TTL 5 分钟 + 更新时主动失效。注意缓存 key 里带上版本号，避免出现"删了缓存但旧值又被写回"的竞态。 优化效果 优 基 + + + 化 线 项 索 批 R 引 量 e 修 查 d 复 询 i 消 s 灭 热 N 点 + 缓 1 存 3 1 耗 0 2 8 时 8 0 0 0 变 0 m m m 化 0 s s s m s 经验总结 优化顺序：先定位（慢日志）→ 再减量（N+1、无用字段）→ 最后加缓存。反过来做等于掩盖问题 不要 SELECT *，只取序列化需要的字段，IO 和网络开销都会显著下降 加缓存前先想清楚失效策略，缓存不一致造成的线上事故比慢接口更难排查

写在前面 以下每一条都来自真实的踩坑教训，按"违反时的代价"从高到低排列。 正文 配置与代码分离。数据库地址、密钥永远不进代码仓库，环境变量或配置中心管理。泄漏一次就足够致命。 所有外部调用必须设超时。HTTP 客户端、数据库驱动、Redis 客户端，默认不设超时的库都会在对方卡死时拖垮你。 日志要能定位问题。关键链路打 traceId；日志带上下文（参数、耗时、结果状态）；ERROR 只留给需要人工介入的事。 重试要配合幂等。网络抖动重试是应该的，但下游接口必须幂等，否则一次超时重试就是两笔订单。 分支合并前必须过 CI。编译、单测、lint 三件套卡在合并前，而不是部署后。坏代码进 main 的成本是卡在分支上的十倍。 数据库变更走迁移脚本。手动改表结构的环境，迟早和代码版本不一致导致无法回滚。 命名宁可长而清楚。retryCountForPaymentGateway 好过 n。代码写一次，读很多次。 删掉的代码就删干净。注释掉的旧代码放两周就没人敢删了，Git 历史本来就是备份。 上线变更要可回滚。每次发布前问自己一句：出问题怎么退？回答不了的发布不上。 文档跟着代码走。接口文档、部署步骤过时比没有更糟。CI 里加文档检查或用代码即文档的工具。 一条隐藏规则 规范本身不重要，重要的是全组用同一套。风格不一致的代码库，维护成本比任何单个坏习惯都高。