腾讯云轻量服务器建站，最省事的就是选应用模板。新建实例时直接挑WordPress或宝塔面板镜像，开机环境就配好了，不用自己敲命令装LNMP。 创建完别急着访问，先去控制台防火墙放行80、443端口，用宝塔的话还得开8888。国内节点记得提前备案，不然域名解析了也打不开。 进面板后一键部署站点，绑定域名、申请个免费SSL证书就行。新手常踩的坑是忘了开端口或者数据库3306对公网全开，后者容易被爆破，建议只允许内网或指定IP访问。 轻量服务器按月流量包计费，超了会额外扣费，上线前最好设个告警。每次改配置前先打个快照，出问题能秒级回滚，比折腾重装系统省太多时间。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请

轻量服务器入口：https://cloud.tencent.com/product/lighthouse 云服务器CVM入口：https://cloud.tencent.com/product/cvm GPU云服务器入口：https://cloud.tencent.com/product/gpu 云数据库入口：https://cloud.tencent.com/product/tdsqlc... 展开详请

消费堆积后「先扩消费者再追赶」的正确姿势，核心是避免三个坑：1. 先搞清堆积的原因再动手：是消费能力不足（消费者处理慢）还是分区数不够？Kafka 一个分区同一消费组内只能被一个消费者消费——如果 Topic 只有 4 个分区，你的消费组里第 5 个及以后的消费者全部空转。所以第一步看消费者 Lag 分布：Lag 集中在部分分区、其他分区是 0 → 分区数不足，扩消费者没用，需要先加分区；所有分区均匀堆积 → 消费处理能力不足，扩消费者有效；2. 扩分区的代价要提前知道：新增分区只对「之后写入的消息」生效，已经堆在旧分区的消息不会被搬迁——旧分区继续由原消费者消化，新流量进新分区。这意味着扩分区不会加速存量堆积的消化，只是防止增量继续堆积。CKafka 控制台扩分区后注意重分区（rebalance）会引起消费者组短暂抖动；3. 安全追赶的顺序：a. 先把消费逻辑里的批处理调大、同步转异步（写 DB 改为先写本地缓冲再批量落库）——纯参数优化经常就能翻倍消费速度，比扩容便宜；b. 扩消费者到分区数以内（不超过），观察消费速率曲线；c. 还不够就扩分区+消费者同步扩，扩分区要评估下游（落库的 DB 扛不扛得住翻倍写入速率——消费加速最容易把下游打挂，这比堆积本身更危险）；d. 极端情况（堆积千万级、消息有时效性）：新建一个补偿 Topic，把过期可丢弃的消息按规则跳过（用 seek 跳到最新 offset，把可丢的历史消息明确丢弃），只追赶有效部分；4. 追赶期间的监控：消费 Lag 曲线要陡峭下降才正常，如果追平后又快速堆积说明消费速率低于生产速率（扩容不够），如果 Lag 不降反升检查是否有消费者反复 rebalance（session timeout 配置不合理）。最后：堆积消化完不是终点，把这次的最大消费延迟告警阈值调严，下次堆积在 1 小时内发现处理成本完全不同。... 展开详请

TC3 签名失败按「拼接 → 加密 → 时钟」三段排查，90% 的问题在前两段：1. 先看具体报错码区分方向：SignatureFailure 是签名不匹配（拼接或加密错）、SignatureExpire 是时间戳问题、SecretIdNotFound 是密钥本身。不同报错排查方向完全不同；2. 拼接的五个高频错误点：a. CanonicalRequest 里的 canonical_headers——每个 header 名必须小写、按字典序排列、header 值 trim 首尾空格且中间连续空格折叠为一个（content-type 的值里多一个空格就会错）；b. SignedHeaders 列表必须与 canonical_headers 实际参与的 header 完全一致（多列或少列都签名失败），分号分隔、小写、字典序；c. Payload 的 SHA256——body 里的中文必须是 UTF-8 编码后哈希，GET 空 body 用空字符串的哈希；d. Content-Type 声明与实际 body 编码不一致（声明 json 但实际发 form-urlencoded）；3. 加密环节：CanonicalRequest → StringToSign（拼日期、service、tc3_request 类型）→ 三层 HMAC 派生链，注意第一层的 key 是字符串 TC3 拼接 SecretKey，service 要填对（cvm、cos、tdmq 各不同，填的是产品 service 代码不是中文名）；4. 时钟：机器时间偏差超过 5 分钟就过期报错，NTP 同步后重试；5. 最快的定位法：用官方 SDK 发同样的请求成功、自己代码失败时，把 SDK 生成的 CanonicalRequest 打印出来与你的逐字符 diff——空格、换行、大小写肉眼很难分辨，必须 diff。用官方文档附的签名生成示例跑出预期值和你的中间值对比，定位到哪一步开始不一致。... 展开详请

先确认过滤是前过滤还是后过滤。多数向量库默认后过滤：先取 topK 向量再按条件筛，如果符合条件的数据只占全集 5%，topK=10 里可能一条都不剩，召回自然崩。 两个动作：把过滤条件作为检索入参交给引擎做 pre-filter（元数据索引要建好），或者把 ef/search_list 调大 3 到 5 倍补偿损失。 租户维度的过滤多，直接按租户分 collection 或分区，比在大集合里硬筛稳，也省得索引退化。 还要看数据本身：删除后没重建索引、更新只写新向量没删旧的，看着也像召回变少。用同一个 query 去掉 filter 跑一遍对比，能立刻分辨是过滤亏了还是数据脏了。... 展开详请

1核1G跑WordPress/Discuz极其勉强，仅适合极轻量测试或纯静态页面。 实测瓶颈： PHP内存溢出：WP默认要求768MB+，1G内存扣除系统开销后，PHP可用内存不足512MB，开启缓存插件极易OOM（Out of Memory）崩溃。 CPU单核打满：Discuz并发稍高或WP加载复杂主题时，CPU瞬间飙升至100%，响应延迟超过3秒。 数据库阻塞：MySQL在低内存下频繁Swap交换，导致查询极慢。 优化方案（若必须用）： 必装OPcache：加速PHP执行，减少重复编译。 极致缓存：前端用CDN+静态化，后端禁用动态查询，使用Redis做对象缓存（需配置得当）。 精简环境：不用宝塔面板（占用资源大），直接用Nginx+PHP-FPM最小配置。 限制后台：关闭所有非必要插件和模块。 建议：至少升级到2核4G，否则体验会很痛苦。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请