作者： sinovale

魔兽世界12.0至暗之夜工程学快速冲80

1，下一个Myu’s Knowledge Points Tracker插件，根据提示在世界各地捡几个宝箱，理论上捡3个（每个3点）就行了。

2，做下图装备直到25点，材料直接拍卖行买

3，工程学专精选择回收，然后点10点，可以在回收时学到新配方

4，买一些粉末颜料，开始用这个作为原料回收。每次回收都有机会学习一些新的配方

5，用类似下图这些回收学习来的配方把技能升到80

魔兽世界12.0.1至暗之夜3月31日职业调整前瞻：暗牧大改，武器战补强，PVP迎来一轮平衡洗牌

相关改动来自 2026 年 3 月 28 日发布、计划于 3 月 31 日到来的《魔兽世界》职业调整蓝帖。

这次调整的思路很明确：一边是针对团本和大秘境开荒前几天的数据，给表现偏弱的专精做一些补强；另一边则是随着 PvP 赛季开启，对过强和过弱的专精进行新一轮修正。整体来看，这不是一次“全面重做”，但不少改动已经足够影响接下来几周的环境。

先说 PvE：几个弱势专精得到直接上调

这次 PvE 方向的加强比较集中，属于很典型的“哪里偏弱补哪里”。

冰DK全伤害提高 4%，野德全伤害提高 3%，但同时单独把“怒意狂乱”伤害下调 8%。暴雪给出的解释也很直白：他们想抬高野德在团队副本里的表现，但又不想继续强化它在地下城里本来就已经不错的伤害能力。换句话说，这不是无脑加强，而是更偏向团本定向扶持。

兽王猎获得 4% 全伤害提升，生存猎则是直接获得 4% 全伤害提高，而且没有写明 PvP 例外，这意味着生存这次属于更直接的增强。奥法方面，日怒相关天赋“力量的重担”被明显上调，奥术冲击和奥术脉冲的收益都比原来高得多，说明暴雪认为奥法日怒流的单体表现确实低于预期。

武器战也得到了一轮朴素但有效的补强：斩杀提高 20%，压制提高 10%，而且明确不影响 PvP。这种改法没什么花活，但对单体和收尾阶段的体验提升会很直接。暴雪自己也承认，武器战当前单体，尤其是斩杀阶段，仍然偏弱。

暗牧是这次 PvE 最值得关注的改动之一

如果只看数字，暗牧这次算是“结构性调整”。

最显眼的是暗言术：灭伤害提高了 80%。这是个非常夸张的数字，暴雪也明确说了，他们认为这个技能过去一直打得不够，哪怕在斩杀阶段也不够亮眼，所以这次是直接下重手修正。

但暗牧并不是纯加强。心灵震爆和虚空冲击伤害下调 10%，同时暗影幻灵和虚空幻灵伤害提高 35%，心智联结、虚空之刺和精神灼烧等多目标相关来源也获得增强。这个信号很清楚：暴雪在重新分配暗牧的伤害结构，把一部分单体直伤压力转移到幻灵和多目标端。

实际效果大概率会是这样：暗牧的斩杀阶段更像斩杀，AOE 和多目标顺劈也会更顺手，但原本靠某些单体技能硬撑面板的感觉会被削弱。对于喜欢暗牧的人来说，这是增强；对于只看木桩秒伤的人来说，得重新适应节奏。

PVP 调整幅度更大，重点是压爆发、抬持续、救弱势治疗

PvP 这次改动比 PvE 更有针对性，而且逻辑很统一：太容易秒人的，压一下；持续太弱的，抬一抬；治疗跟不上版本节奏的，补一口。

射击猎就是典型例子。暴雪认为它的爆发过高，于是把瞄准射击伤害下调 10%，但同时提高夺命射击、黑箭和急速射击的伤害。意思很明确：不想让射击猎一套直接把人抬走，但又不想把这个专精直接砍废，所以把伤害从“峰值”往“持续输出”上挪。

恢复德则是明显吃到照顾的一方。所有治疗提高 8%，愈合提高 40%，迅捷治愈提高 25%，树皮术减伤从 20% 提高到 30%。这套组合拳说明暴雪判断奶德当前不只是奶量偏低，连生存和应对节奏都落后了，所以补得相当明显。

相反，织雾武僧则被继续针对。所有治疗效果降低 4%，而且一些关键冷却相关效果被大砍。暴雪的理由也不拐弯：织雾整个赛季一直太领先，不仅持续治疗强，关键技能转得还快。这一刀下来，织雾大概率还是能玩，但优势没以前那么离谱了。

奥法、火法、惩戒骑、踏风都在调节“爆发窗口”

法师这次 PvP 很有意思。

奥法的奥能之球伤害提高 250%，是个极其抓眼球的数字。这说明这个技能在当前环境里确实掉队太多，暴雪希望它重新回到循环和压制里的存在感。另一方面，火法则被压制燃烧期间的爆发，焚烧殆尽和尽数焚燃在 PvP 中都被削弱，意图就是削掉那种短时间里过于离谱的压血能力。

踏风武僧也属于“压峰值、补短板”的范例。旭日东升踢和疾风呼啸踢被削，怒雷破加强，业报之触吸收量提高。暴雪认为踏风的爆发窗口太短、太难处理，所以要把那种突然抬走人的感觉压下去，同时让它在非爆发阶段也更有威胁，并顺便提高一点生存容错。

惩戒骑这次是有砍有补。通用层面，愤怒复仇对低血量目标的加成从最高 50% 降到 20%，这等于直接削弱了压残血时的斩杀爆发；但作为补偿，圣殿骑士的裁决和最终审判伤害提高 25%，晨光伤害提高 30%。暴雪很明显是不想让惩戒骑的威胁只集中在“低血斩杀”这一瞬间，而是希望它的终结技本身更有分量。

潜行者、增强萨、战士也都被精准下刀或补刀

敏锐贼被削的方向没有悬念，还是针对频繁爆发和整体压制能力。死亡感知和暗影增生相关收益下调后，敏锐在 PvP 里那种“什么都能做，而且伤害还高”的状态会收敛一些。

增强萨则是典型的“整体状态还行，但个别爆发点太过”。暴雪明确说，上周调整后增强整体不错，但配合狂风怒号时爆发过头，所以这次直接砍狂风怒号伤害。与此同时，又把闪电磁索和电刑这类相对边缘的伤害来源大幅抬高，想让技能选择更有价值。

战士方面，武器战 PvP 获得了更好的抗限制能力，战斗姿态对移动限制效果的减免从 10% 提高到 25%，无视苦痛吸收量也提高 20%。这类改动不会让武器战突然变成版本答案，但会明显改善“冲不过去、顶不住”的实战挫败感。狂暴战则是提高斩杀伤害，同时削弱嗜血相关的超模爆发，方向依旧是压缩不合理峰值。

这次改动之后，谁最值得关注？

如果只看 PvE，我认为最值得留意的是暗牧、奥法和武器战。

暗牧不是简单加伤，而是重分配伤害结构，后续很可能会影响天赋、输出节奏和实战手感。奥法则有点像被暴雪“点名扶一把”，如果日怒流原本就差一口气，那这次补丁可能会把它重新推回竞争区间。武器战的增强最朴素，但往往也是最容易体感到的那种。

如果看 PvP，这轮最关键的变化是：射击猎、火法、踏风、敏锐贼这类高压爆发专精会被适当降温，而恢复德、部分萨满和部分圣骑士玩法会得到更强的生存或持续能力。整体环境大概率会比前几天更不容易被“一波带走”，对治疗和拉扯的要求会再提高一点。

总结

这次 3 月 31 日职业调整的核心，不是推翻环境，而是修正赛季初的失衡。

PvE 方面，暴雪在补足几个明显偏弱的专精，尤其是暗牧、奥法、武器战这几个值得重点观察。PvP 方面，则是典型的赛季初二次校准：压低过于夸张的爆发，抬高弱势治疗和边缘伤害来源，让环境别那么极端。

对玩家来说，真正该关注的不是“某个技能涨了多少”，而是暴雪在重新塑造哪些专精的伤害结构和实战节奏。这个影响，往往比面板数字本身更大。

AMH 面板下给小内存 VPS 调 MySQL的配置改法

我这台小 VPS（1 核 1G 左右内存）跑 WordPress，用的是 AMH 面板 + LNMP，数据库是 mysql-generic-8.0。这种配置最大的矛盾很现实：MySQL、PHP-FPM、Redis、Nginx 都要活着，但内存就那么一点点，稍微一波访问就容易 swap、卡顿，甚至 PHP-FPM 一个进程飙 CPU/内存把机器拖死。

所以我给 MySQL 的策略不是“性能拉满”，而是：

  • 稳：不爆内存，不轻易触发 swap 抖动
  • 够用：满足 WordPress 常见读写
  • 可控：参数简单，能在 AMH 里直接粘贴，不用手改一堆

下面记录我这次在 AMH 面板 → MySQL → 参数配置/编辑配置 里调整 MySQL 的过程、思路和最终配置。

1）先说结论：WordPress 场景下，MySQL 8 应该以 InnoDB 为核心

我当时在 AMH 的“中等配置”里看到一行：

default-storage-engine = MyISAM

这在 MySQL 8 + WordPress 上不太合理：

  • WordPress 核心表基本都用 InnoDB（事务、崩溃恢复、行级锁）更合适
  • MyISAM 在并发写入、锁竞争、崩溃恢复方面都不友好
  • MySQL 8 默认其实就是 InnoDB

我也用命令确认过运行时变量（当时查询结果里已经是 InnoDB）：

  • default_storage_engine = InnoDB

所以配置层面我也把它写成 InnoDB，避免“配置写 MyISAM、实际跑 InnoDB”这种割裂状态。

2）我关心的几个关键参数：小内存下要盯住这几项

在 1G 内存的机器上，我重点看的就是：

（1）innodb_buffer_pool_size（核心）

这是 MySQL 内存大头。太大了会挤死 PHP-FPM；太小了数据库命中率差但至少不死。

我的原则：给 InnoDB 128M～256M 这个级别，优先保证系统整体稳定。

（2）max_connections（别给太大）

WordPress 的连接通常来自 PHP-FPM。你机器 1 核 + 1G，开 200 连接只会把自己拖死。

我的原则：30～60 足够，必要时再加。

（3）table_open_cache（适中即可）

过小会频繁 open/close 表；过大又浪费内存。

我的原则：128 或 256。

（4）max_allowed_packet（别搞得太极端）

太小会导致导入/插件操作失败；太大意义也不大。

我的原则：32M（比默认 16M 更稳妥一些）。

3）AMH 面板里怎么改：直接替换“编辑配置”内容

AMH 的好处是它提供了一个“编辑配置”文本框，你可以直接把整段 my.cnf 风格内容粘进去。

我不想一条条点下拉框，所以就用“整段替换”的方式，一次到位。

下面这份就是我给 小内存 WordPress 服务器准备的版本（你可直接复制粘贴到 AMH 的编辑配置里）。

4）最终配置（可直接复制）

说明：按你面板里 mysql-generic-8.0 的路径/命名习惯写的，保持 socket、datadir、pid-file 这些 AMH 自己的字段不动，只把关键性能参数调整到更“稳”的区间。

[client]
port = 3306
socket = /tmp/mysql-generic-8.0.sock

[mysqld]
# 基础路径（保持 AMH 原配置）
port = 3306
socket = /tmp/mysql-generic-8.0.sock
lc-messages-dir = /usr/local/mysql-generic-8.0/share
basedir = /usr/local/mysql-generic-8.0
datadir = /home/usrdata/mysql-generic-8.0
pid-file = /home/usrdata/mysql-generic-8.0/mysql.pid

# 安全/兼容
skip-external-locking
skip-networking
sql_mode='NO_ENGINE_SUBSTITUTION'
default_authentication_plugin = caching_sha2_password
disable_log_bin

# ✅ 关键：WordPress 建议用 InnoDB
default-storage-engine = InnoDB

# 连接与缓存（小内存稳一点）
max_connections = 30
table_open_cache = 128

# 传输包（避免某些导入/插件操作失败）
max_allowed_packet = 32M

# InnoDB 内存（1G 机器建议 128M～256M；先用 128M 更稳）
innodb_buffer_pool_size = 128M
innodb_log_buffer_size = 8M
innodb_open_files = 200

# 一些连接级 buffer：别给太大（并发一上来会放大内存占用）
sort_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
net_buffer_length = 8K
thread_stack = 256K

# MyISAM 相关（基本用不到，但留小一点避免浪费）
key_buffer_size = 8M
myisam_sort_buffer_size = 8M

server-id = 1

[mysqldump]
quick

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

5）改完怎么验证：别信面板，要看运行时变量

我改完后，会用 MySQL 直接查运行时值（避免“配置写了但没生效”）：

mysql -uroot -p -S /tmp/mysql-generic-8.0.sock -e \
"SHOW VARIABLES WHERE Variable_name IN ('default_storage_engine','innodb_buffer_pool_size','max_connections','table_open_cache','max_allowed_packet');"

重点看这几项是不是你期望的：

  • default_storage_engine 是否是 InnoDB
  • innodb_buffer_pool_size 是否按你设定（例如 134217728 = 128M）
  • max_connections 是否为 30
  • table_open_cache 是否为 128
  • max_allowed_packet 是否约 33554432（32M）

6）我为什么这么配：一句话总结

1G 内存的 WordPress 机器，MySQL 的正确打开方式不是“提速”，而是“别抢资源”。
把 InnoDB 用对、把 buffer_pool 限住、把连接数收敛住，整体才稳

买网线踩的坑

昨天突然出现网络断联。经过排查，排除了光猫/路由器/水晶接口的问题，最后用其他网线试了下果然是原网线出了问题。

回想起这条网线从5年前买来至今一直会时不时出现降速到100mbps的情况，但以前从没怀疑过是网线的问题，一直以为是路由器或许长时间没有重启出了问题，重启一下就好了，所以也没有过多在意。直到昨天彻底歇菜。

建议大家在选购网线的时候尽量挑京东自营的大牌购买，其实也没贵几块钱。今天换了新网线后故障解决，网速也能跑到940mbps（千兆宽带），接近物理极限了。