Mesh (Experimental) 下面有 Separate by Materials 。点它以后，模型会按材质槽拆成多个 Blender Object。比如头发材质、皮肤材质、衣服材质、装甲材质可能会分开。它不是按"解剖语义"拆，而是按材质分区拆。Blender 官方的 Separate by Material 也是这个语义：根据不同 face 使用的 material slot，把一个 mesh 拆成多个 object。
"披露"的核心不是告诉散户"明天几点拉盘"，而是回答几个问题：
这个币的流动性是谁在做？
项目方给了它多少筹码？
它拿这些筹码能做什么？
它怎么赚钱？
它有没有被激励去制造波动？
交易所是否知道并监管这个安排？
举个具体结构：
项目 A 要上 Binance。它找 MM 公司 B。项目方借给 B 5000 万枚 token，期限 12 个月，同时给每月 5 万 USDT 服务费。B 的任务是在 Binance、OKX、Bybit 等市场挂买卖单，让价差维持在合理范围内。这个结构如果披露清楚，交易所至少知道 B 手上有大额 token inventory，也知道这些 token 的用途。
但如果合同写成：B 可以低价拿币，之后市场价卖出，利润和项目方分成；或者项目方承诺 B 一年必须赚 20%；那就很危险。因为 B 的最佳行为可能不是"稳定流动性"，而是"制造上涨、吸引散户、然后卖出"。这就是为什么 Binance 要禁止 profit sharing 和 guaranteed return。CoinDesk+1
Binance 2026 年这类"披露"主要是项目方向 Binance 披露 ，不是 Binance 在每个币的交易页给散户公开标注"MM = 某某公司"。公开报道里的表述是 token issuers / projects must disclose market maker identity、legal entity、contract terms to Binance，也就是项目方要把做市商身份、法律实体、合同条款交给平台审核。CoinDesk+1
普通用户在交易界面主要看到的是价格、成交量、订单簿深度、资金费率、未平仓量、K 线、公告、合约规则等。一般不会直接看到"这条买单来自哪家做市商"或"该币官方 MM 是谁"。这也是合理的：如果实时公开某个做市商身份和具体库存，反而可能被其他交易者针对性攻击，造成流动性撤退。
返程推进剂 / 氧气 / 水 ：这是 SpaceX Mars 方案里最关键的"就地取材"方向，也就是 ISRU。基本想法是用火星大气中的 CO₂，加上火星水资源，制造氧气和甲烷；甲烷和液氧正好对应 Starship 的 Raptor 发动机推进剂体系。学术界也普遍认为，火星长期驻留要依赖 ISRU 来供应燃料、水和氧气。PMC+1
SpaceX = 公司
Starship = SpaceX 的大型可重複使用火箭/飛船系統
Super Heavy = Starship 系統的第一級助推器
Raptor = Starship / Super Heavy 使用的發動機
Starlink = SpaceX 的衛星網路業務，也會用 Starship 大批量發射衛星
源角色的哪一段骨骼，要对应到目标角色的哪一段骨骼。
官方文档对 Retarget Chains 的定义就是：在 IK Rig 里定义骨骼链，然后 IK Retargeter 根据这些 chain 把动画从一个角色转到另一个角色；创建时要选链的第一个骨骼，一直选到链的最后一个骨骼。Epic Games Developers
Chain Name 是这条链的名字。
比如 Pelvis、Spine、LeftArm、RightLeg、Head、LeftHand。这个名字非常重要，因为 Source IK Rig 和 Target IK Rig 主要靠 chain name 互相匹配。名字不一致，就要手动映射。
Chain Name 是这条链的名字。
比如 Pelvis、Spine、LeftArm、RightLeg、Head、LeftHand。这个名字非常重要，因为 Source IK Rig 和 Target IK Rig 主要靠 chain name 互相匹配。名字不一致，就要手动映射。
Start Bone 是这条链开始的骨骼。
比如腿链通常从 thigh_l / 左足 / 左ひざ 之类的上级骨开始；手臂链通常从 upperarm 开始；脊柱链从 spine/pelvis 附近开始。
End Bone 是这条链结束的骨骼。
比如腿链一般结束到 foot 或 toe；手臂链结束到 hand；头链结束到 head。
Goal 是可选的 IK Goal。
不是每条链都必须要 Goal。Goal 更偏向 IK 约束目标，比如脚掌、手掌这种末端需要更稳定贴合的位置。官方 IK Rig 文档里也说，IK Goal 通常是手或脚这类 IK chain 的 ending bones，用于创建 IK 控制目标。Epic Games Developers
你右边圈出的 IK Retargeting 面板，就是当前 IK Rig 里已经定义的 Retarget Chain 列表。你现在显示的是：
Pelvis: 腰
意思是你已经把日文骨骼 腰 设置成了 Pelvis 相关的重定向骨骼/链。UE 5.7 文档里也单独提到 Pelvis：除了定义 chains，还需要定义 pelvis bone，因为它用于按比例传递 root motion；设置后会在 Hierarchy 和 IK Retargeting 面板里显示。Epic Games Developers
这里最容易误解的是：Chain 不是骨骼本身，Chain 是 UE 给骨骼段加的"语义标签"。
骨骼原本只是层级：
腰 → 下半身 → 左足 → 左ひざ → 左足首 → 左つま先
UE 不知道这段到底是"左腿"还是"裙子链"还是"机械尾巴"。你创建 Retarget Chain，就是告诉 UE：
"从 左足 到 左つま先，这整段叫 LeftLeg。"
"从 左腕 到 左手首，这整段叫 LeftArm。"
"从 首 到 頭，这整段叫 Head。"
然后 IK Retargeter 才能做这种映射：
Source LeftLeg → Target LeftLeg
Source RightArm → Target RightArm
Source Spine → Target Spine
Set Pelvis 是一个全局特殊标记 ，而 RightArm / LeftLeg / Spine / Head 这些不是全局标记
是Retarget Chain。
pelvis bone；它用于让角色的 root motion / 身体中心运动按比例传递。
Retarget Chain 不要求 source 和 target 的骨骼数量相同。**它要求的是：你在 target 上标出一段"从 Start Bone 到 End Bone 的连续骨骼范围"，然后把这段范围映射到 source 的某条 chain。
pelvis bone，用来让 root motion / 身体中心运动按比例传递
Full Body IK 解算器单独加了一份"骨骼设置"。
Full Body IK bone settings 是给 IK 解算器看的，不是给 Retarget Chain 映射看的。
Source：RightArm
Target：RightArm
那 Auto Map Chains / 自动映射通常就能直接匹配。UE 的 IK Retargeting 文档也把 retarget chain 作为从一个 IK Rig 映射到另一个 IK Rig 的单位；官方 Blueprint API 里也有 Auto Map Chains、Get Source Chain、Set Source Chain 这类接口，说明 chain 映射是可以自动也可以手动指定的。Epic Games Developers+1
骨架本身必须是树形/层级结构。
Retarget Chain 只是从这棵树里截取一段连续的父子路径。
所以 LeftArm 不需要从 root、center、pelvis 开始。它可以只定义：
左腕 → 左ひじ → 左手首
这条链没有包含 センター / グルーブ / 腰，但它仍然是合法 chain，因为在骨架树内部，左腕 到 左手首 是一条连续父子路径。
Preview Offset > Target Mesh Scale 这个 scale 不是"把模型在自己脚底原地缩放"的建模工具。它是 Retargeter 预览层的缩放，用来比较 source/target 预览模型。它会围绕 Retargeter 当前使用的目标根/预览根位置工作。如果 target root 是 None，或者 root/pelvis remap op 配置异常，就会围绕错误参考点缩放。
所以你现在不要继续调 Target Mesh Scale。先修根参考。
第一步，去 IK_Aglina，删除普通 Root chain。你现在之前试过 Root = 腰 → 腰 或 Root = 全ての親 → 全ての親，这两种都在制造混乱。腰 已经是 Pelvis，不要再拿它当 Root chain。日志里的 Root chain too short 就是这个问题还没清掉。
Retargeter 内部是一个操作栈。你在 IK Rig 里设置 pelvis，只是给它提供数据源；具体的 Retargeter Op 还要能正确初始化并读取这个数据。Epic Games Developers+1
你日志里这几句非常关键：
Root Motion Remap Op, missing source root bone None.
Root Motion Remap Op, missing target root bone None.
Root Motion Remap Op, missing target pelvis bone None.
这说明正在报错的不是你左侧看到的 Pelvis: 腰 那个标记本身，而是 Root Motion Remap Op 里的 source root / target root / target pelvis 配置是 None。
在骨骼綁定中，角色的脊椎、腰部和骨盆的骨骼通常是連動的。當角色進行大動作（如揮劍、奔跑或迴避）時，腰部的晃動或位移可能會導致整體動作顯得僵硬或不自然。
Waist Cancel （直譯為「腰部抵銷」或「腰部過濾」）是指在動畫樹（Animation Tree）或骨骼控制器中， 設定限制，讓某部分的動畫或物理效果不去影響（抵銷）特定的腰部骨骼
維持上半身穩定（Layered Blend per Bone）： 例如角色在跑步或受傷時，腰部以下的骨骼負責執行移動或跌倒動畫，但透過 Waist Cancel，可以保護腰部和胸部骨骼不受下半身劇烈動畫的影響，讓上半身（如持槍瞄準或上半身表情）能獨立、平穩地執行其他動作。
在加入布料模擬或物理骨骼（如飄逸的裙擺或腰帶）時，利用 Waist Cancel 避免腰部本身的基礎動畫與外掛的物理系統產生衝突與抖動。 [1](https://www.reddit.com/r/UnrealEngine5/comments/15rivcl/bone_animation_removal/ "1")
FK (Forward Kinematics) Retarget 是透過記錄和驅動關節的「旋轉角度」來轉移動畫的方式。
為什麼它又被叫做 "IK" Rig / "IK" Retargeter？
因為這套系統 同時支援 IK 修正 。
- 解決穿模與浮空：如果只用 FK（旋轉），當目標角色的腿比較長時，它的腳就會踩進地表下或懸空。
- 引入 IK 目標 ：在同一個 Chain 的末端（如腳踝）加上一個 IK Goal，系統就會在 FK 旋轉的基礎上，使用 IK 原理 強迫腳掌必須精準踩在地面上。
在 Chain 上面綁定 IK Goal（解算器） 來修正動作
Chain Mapping：Source Chain -> Target Chain。
Retarget Ops：真正执行 pelvis motion、FK chains、IK chains、IK solve、root motion 的操作栈。
UE 5.7 的 Retargeter 不是单一开关，而是 Op Stack。官方 5.7 API 里 AddDefaultOps() 明确写着默认会添加这些操作：Pelvis Motion、FK Chains、IK Chains、IK Solve、Root Motion。Epic Games Developers
所以你现在能动，说明至少 FK Chains 这一块有部分生效。但缩放中心不对，通常不是 FK chain 本身，而是 root/pelvis/root motion/preview pivot 相关设置还没有对上。
Retarget Pose / Auto Align
这是"姿势对齐"层。它解决的是 A pose、T pose、肩膀角度、腿张开角度、骨骼朝向差异。官方文档里 Reset 是重置 retarget pose，Auto Align 是自动对齐 source/target 骨骼姿势。
不会从根本上改变模型的真实 pivot，也不会修复 skeletal mesh 的导入原点。如果缩放中心偏离，这层只能部分改善视觉对齐，不能保证根参考正确。
Editing Retarget Pose ：你在编辑"姿势偏移"。
Running Retarget：你在运行"动画重定向结果"。
你说"Run Retarget 时候恢复到原位，但是绿线消失了"，这说明之前那条绿线大概率不是模型资产本身的永久错误，而是 Editing Retarget Pose 模式下的调试/编辑骨骼显示。进入 Running Retarget 后，UE 不再显示那个被选骨骼/目标骨架的编辑辅助线，所以它消失了。
twist 骨把旋转分布到一段网格上，让手臂、腿的变形更自然。
你移动 goal，Full Body IK solver 再反算腿、手、身体该怎么跟过去。
官方 IK Rig 文档也是把 IK Goal 描述成用于操控 IK chain 的目标，而不是让你直接改每根骨骼本身。
同时存在 骨架节点 和 IK 解算目标/控制目标。
在 IK Rig Editor 裡，Hierarchy 這個區域顯示的是 IK Rig 的「可解算元素樹」，不是 Skeleton Editor 裡那種只看 Skeleton bone 的樹。
官方 Python 文檔講得很直：IK Rig consists of multiple parts，其中 Hierarchy 包含 bones, goals, goal settings, and bone settings；Solver 會影響 hierarchy 裡的 bones 以及它們之間的關係。也就是說，你在 Rig Element 裡看到的不只是原始骨骼，還會看到 IK Goal、Goal Settings、Bone Settings 這些 IK Rig 資產額外加上去的元素。
橙色通常是在顯示 Solver 的 root / pelvis / 被解算的起點骨骼或骨骼參考點 。
綠色通常是在顯示 IK Goal / effector，也就是 solver 要拉到的位置。
IK Solver 通常需要 root Bone、IK Goal，或兩者一起指定；root Bone 是 chain 起點，goal/effector 是 chain 末端，被 IK Goal 驅動。這才是你看到「一個像父、一個像子」的原因：它們剛好對應 IK 解算的起點和終點，但不是普通骨架 hierarchy 裡的父子顏色規則。Epic Games Developers
所以可以用這個心智模型：
橙色 = 這條 IK/Retarget 解算從哪裡開始受控
綠色 = 這條 IK/Retarget 解算想把末端拉去哪裡
第一類是 Retarget Chains：描述哪些骨骼構成手臂、腿、脊椎、頭。這部分主要是 FK 語義，因為動畫本身通常是骨骼旋轉沿父子鏈傳遞。
第二類是 IK Goals / Solvers：描述腳、手這些末端控制點如何被 IK solver 拉動。這才是狹義 IK。
第三類是 Retarget Root / Pelvis / Pose：描述整個角色的根、骨盆、比例、姿勢基準。這是 retarget 的全局對齊層。
所以你說得對：Retarget Chain 本身很大程度是 FK 原理 。它只是在 IK Rig asset 裡配置，因為 retarget 需要同時知道「FK 鏈條語義」和「IK 末端約束」。Epic 的 IK Rig Retargeting 文檔說，動畫 retargeting 是讓不同 skeleton 之間共享動畫，而 IK Retargeter 要依賴 source/target 的 IK Rig 資產；Auto Retargeting 也會自動生成 IK Rig assets 和 IK Retargeter asset。這說明 IK Rig 在這套系統裡承擔的是 retarget 描述層，不只是 IK 解算器。Epic Games Developers+1
橙色是「終點/目的地」 ，而 綠色是「計算過程與受影響的骨骼」。
Limb IK（四肢IK） 還是 Full Body IK（全身IK）
足D_L、ひざD_L、足首D_L、足先EX_L
这可能是 deform / display / derived 类链，常见于 MMD 转换后的骨架。它可能参与实际蒙皮，也可能是辅助变形链。要看它是否真的沿腿部走、是否影响 mesh。
足首補助_L、足首補助2_L、ひざ補助_L
这是典型"补助骨"。用途通常是修正膝盖、脚踝、腿部扭转、局部变形，让动画在 MMD 里看起来更自然。
如果 足D_L -> ひざD_L -> 足首D_L -> 足先EX_L 是一條連續、貼著腿走、會帶動網格變形的鏈，那它可以作為 LeftLeg 的候選主鏈。
如果它只是跟在 足_L / ひざ_L / 足首_L 旁邊的補助鏈，或者只是控制/修形/抵消用途，那第一輪不要拿它做 Retarget Chain。
D 骨通常不是從"解剖清晰"出發，而是從"修正變形"出發。
普通骨架是給人看的：大腿、膝、腳踝、腳尖。D 骨是給變形系統用的：哪裡折得難看，就在那裡加一層跟隨、抵消、補助、延伸。這會讓層級看起來不像一條乾淨的人體腿，而像工程補丁。
MMD 的準標準骨體系本來就混合了控制、補助、IK、變形。
足D / ひざD / 足首D / 足先EX 這些經常和 補助、キャンセル、IK 類骨一起出現。它們不是 UE Manny 那種面向遊戲引擎 retarget 的清潔骨架，而是面向 MMD 動作、VMD、PMX 變形、IK 操作習慣的骨架。MMD 輔助骨介紹裡也把 足D / ひざD / 足首D 放在 assist bones 的語境下，說它們在極限動作時比基礎骨更方便，但注意事項更多。
導入到 UE 後，MMD 的"控制層"被展平成 UE 的 Skeleton hierarchy。
在 MMD/PMX 裡，某些骨的意義可能依賴「付与親」「變形階層」「IK」「顯示枠」這些 PMX 概念。進 UE 後，你看到的是一棵普通父子骨骼樹。原本在 MMD 裡是"控制規則"的東西，進 UE 後就變成一堆看起來很奇怪的 bone branch。這就是你感覺 D 內部更亂的根本原因：語義沒有消失，但顯示方式變粗暴了。
一个经验性提示：MMD 里腿部经常受 IK 控制，普通腿骨不一定像 Blender/UE 的 FK 骨那样直接响应。LearnMMD 的 Blender/MMD Tools 教程也提醒，腿骨可能因为受 IK 骨控制而"不怎么响应"，移动腿时应尝试移动 IK 骨。learnmmd.com 这正好解释你现在的困惑：MMD 模型里的腿不是一条纯 FK 链，而是"FK 主骨 + IK 控制骨 + 补助/变形骨"的混合结构。
「グループ」意思是「群組」或「Group」。
- 控制全身位移 ：它是用來控制整個角色身體重心移動的骨骼。
- 與「全ての親（總體母骨骼）」的差別 ：
- 全ての親（總控骨）：移動它時，角色的腳會黏在地上跟著走，通常留在地面坐標的原點。
- センター（中心骨） ：移動它時，角色會做出「蹲下」、「跳躍」或「身體重心前後左右擺動」的動作，此時雙腳（如果啟用了 IK 反向動力學）會固定在地面上不變。
簡而言之，這根骨骼主要是讓你在做動畫時，用來 控制角色臀部與上半身整體的重心位置 。
「Center」的日文是外來語，寫作 「センター」 。
- 平假名：せんたー
-
先備份
.blend。 -
選
洁尔佩塔_arm。 -
切 Edit Mode。
-
選左、右兩根綠骨，再最後選中中間灰/黑骨。
-
Ctrl + P→ 選 Keep Offset。 -
回 Pose Mode，旋轉中間骨，看兩側骨是否跟隨。
-
如果跟隨方向對，再測 UE 導出。
-
不要先選 Connected，除非你確定那兩根綠骨的 head 本來就應該和中間骨 tail 重合。
你圖裡這種左右兩根骨頭分別在身體兩側，中間骨在骨盆附近，從骨架語義上更像是：
中間骨 / pelvis / 下半身 / 腰キャンセル
作為父級，左右腿或左右控制骨 Keep Offset parent 到它。
不是把中間骨 tail 物理焊到左右兩個 head 上。那會變成一個錯誤的 Y 形 connected chain，而 Blender/UE 的骨架實際上只接受「一根 child 有一個 parent」的層級，不是同一個 tail 同時焊兩個局部初始段來解算。
https://chatgpt.com/s/t_6a17f7b6e7688191a1716a242d0caf3f
- Unreal Engine 官方文件： 搜尋 「Skeletal Mesh Animation Rigging Specifics」。Epic Games 嚴格規定了 Root（根骨骼）與 Pelvis（骨盆骨骼）的關係，並解釋了為什麼兩者不能亂接。
- Unity 官方文件： 閱讀關於 「Humanoid Avatar (人形骨架映射)」 的規範。Unity 的 Humanoid 架構要求極其嚴格，如果骨骼方向相反或層級不對，系統會直接變紅燈報錯。
- 軸向碰撞（Flip Issue）： 兩個相連但方向相反的骨骼，在旋轉時會導致座標軸（Local Axis）混亂，動畫師在調動作時會發現數值暴走。
- 無法做 Root Motion（根運動）： 遊戲需要提取最底層根骨骼的位移來讓角色在遊戲裡真正移動。如果上面黏了另一根核心骨骼，引擎會無法分辨該提取哪一個。
WXML：重点是数据绑定、列表、条件、事件
WXML 不是 HTML 替身这么简单。考试常问的是四种语法：
overflow-visible!
XML
<view>{{msg}}</view>
<view wx:if="{{isShow}}">显示</view>
<view wx:for="{{list}}" wx:key="id">
{{item.name}}
</view>
<button bindtap="handleTap">点击</button>你要记住：{``{ }} 是数据绑定；wx:if 是条件渲染；wx:for 是列表渲染；bindtap 是事件绑定。wx:if 可以配 wx:elif、wx:else 使用；wx:for 循环时默认当前项叫 item，下标叫 index。
考试如果问 wx:if 和 hidden 区别，标准答法是：wx:if 控制节点是否渲染，条件不成立时节点不生成；hidden 更偏向显示/隐藏，节点仍然存在。频繁切换用 hidden，条件变化少用 wx:if。
JS：重点是 Page、data、setData、事件对象
小程序页面逻辑写在页面 .js 里，核心结构是：
Page({
data: {
msg: 'hello',
count: 0
},
handleTap() {
this.setData({
count: this.data.count + 1
})
}
})
Page({
onLoad(options) {
// 页面加载，一个页面生命周期内通常只触发一次，可拿路由参数
},
onShow() {
// 页面显示，每次进入/返回该页面都可能触发
},
onReady() {
// 页面初次渲染完成
},
onHide() {
// 页面隐藏
},
onUnload() {
// 页面卸载
}
})考试答法可以直接写：onLoad 是页面加载时触发，适合初始化和接收参数；onShow 是页面显示时触发，返回页面也会触发；onReady 是首次渲染完成；onHide 是页面隐藏；onUnload 是页面卸载。51CTO Edu+1
radio 不要单独背，核心是它通常放在 radio-group 里，radio-group 通过 bindchange 监听变化，
从 e.detail.value 里拿。radio 的 value 是选中后传出的值，checked 表示默认选中，disabled 表示禁用。Tencent Cloud+1
<radio-group bindchange="radioChange">
<label wx:for="{{items}}" wx:key="value">
<radio value="{{item.value}}" checked="{{item.checked}}" />
{{item.name}}
</label>
</radio-group>JavaScript
Page({
data: {
items: [
{ value: 'A', name: '选项A', checked: true },
{ value: 'B', name: '选项B' }
]
},
radioChange(e) {
console.log(e.detail.value)
}
})view.container 是"整页容器"，负责给整个页面加内边距、背景、整体布局。里面的 view.title 是标题区域，view.current 是当前选择的文字区域。radio-group 本身就是单选组容器，所以它里面不用再额外套一层 view，除非你要给整个单选区加背景、边框、间距。
class="container"、class="title"、class="option" 这些是你自己起的样式类名 ，微信本来没有。你可以叫 container，也可以叫 box、main、abc。只要 WXML 里的 class 名字和 WXSS 里的 .类名 对上就行。
<view class="title">选择你的复习重点</view>这里：
view = 微信提供的组件
class = WXML 属性
title = 你自己起的类名然后你要在 WXSS 里写：
CSS
.title {
font-size: 36rpx;
}如果你把 WXML 改成：
XML
<view class="my-heading">选择你的复习重点</view>那 WXSS 就要改成：
CSS
.my-heading {
font-size: 36rpx;
}这和 UE 里"控件类型"和"变量名/样式名"不是一回事。view 是控件类型，title 是你给这个控件贴的样式标签。
radio 到底做什么：它就是单选按钮 。用途是"多个选项里只能选一个"。比如性别、答案 A/B/C/D、配送方式、支付方式、复习重点，只能选一个时就用 radio。官方组件体系里，radio 属于表单组件，通常和 radio-group 搭配使用；radio-group 会在内部 radio 状态变化时触发 change 事件，事件里能拿到当前选中的 radio 的 value。WXSS 方面，app.wxss 是公共样式，会注入每个页面，页面同名 .wxss 是当前页面样式。Tencent Cloud
关键点是：一个 radio 只是一个选项，radio-group 才是一组选项的管理者。
<radio-group bindchange="onRadioChange">
<radio value="A" /> A
<radio value="B" /> B
<radio value="C" /> C
</radio-group>这表示 A/B/C 三个选项只能选一个。用户选 B 时，radio-group 触发 change，然后 onRadioChange 里能拿到 "B"。
为什么要写 bindchange？因为你需要知道"用户选了哪个"。如果只是显示几个单选按钮，不需要处理结果，可以不写。但考试和实际项目里通常要拿选择结果，所以写：
XML
<radio-group bindchange="onRadioChange">意思是：当这一组单选按钮的选中项发生变化时，执行当前页面 JS 里的 onRadioChange 函数。
item 是在哪里定义的？它不是你在 JS 里直接写的变量名，而是 wx:for 循环时小程序自动给当前循环项起的默认名字。
看这个：
JavaScript
Page({
data: {
items: [
{ value: 'radio', name: '4.4.8 radio' },
{ value: 'navigator', name: '4.5 navigator' }
]
}
})这里你定义的是 items，一个数组。
关于 navigator，你这里混了两个概念：页面跳转组件 navigator 和 底部 tabBar 导航栏。
navigator 不是底部栏本身。navigator 是写在某个页面 WXML 里的一个可点击跳转组件，类似页面里的一个链接按钮。
例如首页里写：
XML
<navigator url="/pages/result/result">
查看结果
</navigator>这是页面内容的一部分，放在 pages/index/index.wxml 里。
而底部栏 tabBar 是全局配置，确实写在 app.json 里：
JSON
{
"pages": [
"pages/index/index",
"pages/mine/mine"
],
"tabBar": {
"list": [
{
"pagePath": "pages/index/index",
"text": "首页"
},
{
"pagePath": "pages/mine/mine",
"text": "我的"
}
]
}
}所以结论是：
navigator：页面里的跳转组件，写在某个 page 的 .wxml 中。
tabBar：小程序底部导航栏，写在 app.json 中。如果你要从普通页面跳到普通页面，用：
XML
<navigator url="/pages/result/result">查看结果</navigator>如果你要从页面内容里跳到底部 tabBar 页面，用：
XML
<navigator url="/pages/index/index" open-type="switchTab">回首页</navigator>如果你要配置底部栏本身，那不是写 navigator，而是写 app.json 的 tabBar。
把这些连起来看，完整逻辑是：
XML
<!-- pages/index/index.wxml -->
<view class="container">
<radio-group bindchange="onRadioChange">
<label wx:for="{{items}}" wx:key="value">
<radio value="{{item.value}}" />
<text>{{item.name}}</text>
</label>
</radio-group>
<navigator url="/pages/result/result?type={{selectedValue}}">
查看结果
</navigator>
</view>JavaScript
// pages/index/index.js
Page({
data: {
items: [
{ value: 'radio', name: '4.4.8 radio' },
{ value: 'navigator', name: '4.5 navigator' }
],
selectedValue: ''
},
onRadioChange(e) {
this.setData({
selectedValue: e.detail.value
})
}
})CSS
/* pages/index/index.wxss */
.container {
padding: 32rpx;
}e 就是事件对象 ，也常叫 event。它不是固定只能叫 e，只是程序员常用缩写。
这两个写法等价：
JavaScript
onRadioChange(e) {
console.log(e.detail.value)
}JavaScript
onRadioChange(event) {
console.log(event.detail.value)
}它的来源是：当用户操作页面时，比如点击、输入、切换 radio，小程序会自动调用你绑定的函数，并把"这次事件的信息"作为参数传进来。
比如你写了：
XML
<radio-group bindchange="onRadioChange">
<radio value="radio" /> radio
<radio value="navigator" /> navigator
</radio-group>然后 JS 里写：
JavaScript
Page({
onRadioChange(e) {
console.log(e.detail.value)
}
})当用户选中 navigator 这个 radio 时，小程序会自动执行：
JavaScript
onRadioChange(这次change事件的信息)这个"这次 change 事件的信息"就是 e。
对 radio-group 来说，最重要的是：
JavaScript
e.detail.value它表示当前选中的 radio 的 value 值。
所以：
XML
<radio value="navigator" /> navigator用户选中它以后：
JavaScript
e.detail.value结果就是：
navigator你可以把它理解成：
e = 这次事件的报告单
e.detail = 这次事件的详细数据
e.detail.value = 这次 radio-group 改变后选中的值class 管"长什么样"。
wx:for 管"重复生成几个"。
wx:if 管"要不要生成"。
可以写在 view 上，也可以写在 text、label、navigator、radio 等很多组件上，不是只能写在 view 里。官方 WXML 语法里，wx:for 用于列表渲染，wx:if 用于条件渲染。Google Play
比如：
XML
<view class="option" wx:for="{{items}}" wx:key="value">
{{item.name}}
</view>这句话的意思不是"执行 .option 这个 class"。它的真实顺序是：
1. 去 JS 的 data 里找 items 数组
2. items 有几项，就生成几个 <view>
3. 每个生成出来的 <view> 都带 class="option"
4. class="option" 再去 WXSS 里找 .option 的样式假设 JS 是：
JavaScript
Page({
data: {
items: [
{ value: 'radio', name: 'radio 单选' },
{ value: 'navigator', name: 'navigator 跳转' }
]
}
})那么这段 WXML：
XML
<view class="option" wx:for="{{items}}" wx:key="value">
{{item.name}}
</view>运行后大概等于生成了：
XML
<view class="option">radio 单选</view>
<view class="option">navigator 跳转</view>所以 wx:for 是"复制组件"，不是"执行样式"。
但是 item 不需要你在 JS 里写：
JavaScript
data: {
item: ...
}因为 item 是 wx:for 自动生成的临时变量。它表示"当前循环到的那一项"。
<view>{{msg}}</view>这个写法成立的位置是：WXML 文件里，例如：
pages/index/index.wxml它叫数据绑定 ，或者叫 Mustache 语法 。WXML 用 {``{变量名}} 绑定当前页面 JS 文件 data 里的属性。也就是说，{``{msg}} 会去同页面的 .js 文件里找 data.msg。Tencent Cloud
对应 JS 是：
JavaScript
// pages/index/index.js
Page({
data: {
msg: '你好，小程序'
}
})对应 WXML 是：
XML
<!-- pages/index/index.wxml -->
<view>{{msg}}</view>页面显示结果就是：
你好，小程序这里为什么没有逗号？因为 {``{msg}} 不是在"定义对象"，而是在"读取一个变量"。
在小程序里：
JavaScript
Page({
data: {
msg: '你好'
}
})可以拆开看：
Page = 微信小程序提供的函数 / 构造器
(...) = 调用这个函数
{...} = 传给 Page 的参数对象
data: {...} = 这个对象里的一个配置项所以 Page({ ... }) 的意思是：调用微信提供的 Page 函数，并把一个页面配置对象传进去，让小程序框架根据这个对象创建页面。
App() 也是同理：
JavaScript
App({
onLaunch() {
console.log('小程序启动')
},
globalData: {
userInfo: null
}
})
题目说"通过 navigator 传来的参数在哪里接收"，答案是 onLoad(options)。
data 是页面初始数据，WXML 可以通过 {{}} 绑定。修改 data 并刷新页面显示时，应使用 this.setData()。
rpx 是小程序的响应式尺寸单位，可根据屏幕宽度自适应。flex 用于弹性布局，justify-content 控制主轴对齐，align-items 控制交叉轴对齐。
Page({
data: {
id: '',
title: ''
},
onLoad(options) {
console.log(options.id) // 1001
this.setData({
id: options.id,
title: '详情页'
})
},
onReady() {
console.log('页面第一次渲染完成')
}
})这里 id=1001 要在 onLoad(options) 里拿，不是在 onReady() 里拿。onReady() 不是用来接参数的。
onReady 也不会自动清缓存 。清缓存是另一类 API，比如本地缓存相关要用 wx.clearStorage()、wx.removeStorage() 之类。生命周期函数本身不会帮你清任何缓存。它只是告诉你"页面到了哪个阶段"。
onReady 的重点是"第一次渲染完成"。一个页面实例生命周期内通常只触发一次。它不是"每次显示都触发"。每次显示主要看 onShow。
为什么是 {}？因为它允许一次改多个数据：
JavaScript
this.setData({
msg: '新的文字',
count: 10,
isShow: true
})这就等于一次更新：
data.msg
data.count
data.isShow
<view class="container">
<view class="title">标题</view>
<radio-group bindchange="onRadioChange">
<label class="option">
<radio value="A" />
<text>A 选项</text>
</label>
<label class="option">
<radio value="B" />
<text>B 选项</text>
</label>
</radio-group>
</view>真实结构是：
view.container
├─ view.title
├─ radio-group
│ ├─ label.option
│ │ ├─ radio
│ │ └─ text
│ └─ label.option
│ ├─ radio
│ └─ text看到 <view class="container">，它会一直包到对应的 </view> 为止。
看到 <radio-group>，它会一直包到 </radio-group> 为止。
看到 <label>，它会一直包到 </label> 为止。
看到 <radio value="A" />，这个最后的 /> 表示它自己结束，不再包任何东西。
第一种，有开始和结束：
XML
<view>
内容
</view>第二种，自闭合：
XML
<radio value="A" />自闭合标签的意思是：这个组件自己结束，不包子节点。
radio 可以写成自闭合 ，也可以写成开始标签 + 结束标签。这两种都能成立。
自闭合写法：
XML
<radio value="A" />
<text>A 选项</text>完整闭合写法：
XML
<radio value="A"></radio>
<text>A 选项</text>这两种意思基本一样：radio 自己是一个单选按钮组件，后面的文字通常用 text 或普通文本另写。
但更推荐你考试里写自闭合：
XML
<radio value="A" />因为 radio 本身通常不需要包内容。它不像 view、label、navigator 那样经常包子节点。
一块不要和 navigator 组件混：navigator 是写在 WXML 里的组件；下面这些是写在 JS 里的 wx.xxx() 方法。页面导航核心 API 包括 wx.navigateTo、wx.navigateBack、wx.redirectTo、wx.reLaunch、wx.switchTab。CSDN Blog
11.4.1 跳转到新页面 wx.navigateTo
11.4.2 返回指定页面 wx.navigateBack
11.4.3 当前页面重定向 wx.redirectTo
11.4.4 重启页面 wx.reLaunch
11.4.5 切换 tabBar 页面 wx.switchTab最重要的是看它们对页面栈的影响。
wx.navigateTo
保留当前页面，跳转到新页面。
旧页面不会销毁，只是 onHide；新页面 onLoad → onShow → onReady。
适合：从列表页进入详情页。当一个微信小程序页面被 unload （卸载）后，它在内存中的实例就被销毁了。
再次跳转该页面的生命周期流程
下一次当您再次通过 wx.navigateTo 或其他跳转方式进入这个页面时，该页面会 作为一个全新的页面 重新经历完整的生命周期。执行顺序如下：
onLoad（重新触发）：页面加载，重新接收路由携带的参数。onShow（重新触发）：页面显示，开始渲染视图。onReady（重新触发）：页面初次渲染完成，可以获取组件实例或进行节点操作。
当比特币的链上交易成本超过黄金时，它的演变路径并不会走向崩溃，而是会直接复制"黄金本位制"在人类历史上的演化逻辑 。
人类历史上，当黄金因为太重、运输成本和安保成本太高（类似于比特币主网Gas费太高）时，人类发明了纸币（黄金代用券）和银行清算系统。
未来比特币面对这个问题，主要通过以下三种层级来解决和分流：
第一层：逻辑重塑 ------ 主网不再是"钱包"，而是"金库"
如果把实物黄金从中国运到美国，需要租用装甲车、飞机、买高额保险，其 单次运输成本高达数万美元 。但为什么黄金没有因此被废弃？
因为大资金不需要每天搬运黄金。
- 未来的比特币主网（Layer 1） ：定位就是数字金库。
- 交易特征 ：中央银行、跨国集团、主权基金之间，单笔结算金额可能高达数亿甚至数十亿美元。对于 1 亿美元的结算，即使主网收 5000 美元的 Gas 费（费率仅 0.005%），也远远比实体黄金的跨国运输更便宜、更安全、更快速（10分钟到账，无需安保）。
- 结论 ：主网高成本是可以接受的，因为它只服务于高价值的"终极清算"。
第二层：技术分流 ------ 闪电网络与二层清算（Layer 2）
普通人每天买咖啡、买衣服，绝不可能去搬运实物黄金，同理，未来普通人也不会直接用比特币主网转账。
- 机制：通过闪电网络（Lightning Network）或侧链（如 Fedimint、Liquid）。
- 原理：这相当于大家把比特币锁在主网（金库），然后在二层网络上打借条（类似于纸币）。上百万人在二层网络上进行微秒级、零费用的互相转账，只有在最终需要"分家"或提现时，才打包成一笔交易提交给主网。
- 结果 ：普通人的交易成本被降低到忽略不计（甚至低于现在的信用卡刷卡费） 。
第三层：机构化与影子化 ------ ETF、数字资产托管
就像今天绝大多数投资黄金的人，家里并没有金条，而是购买了 黄金 ETF（如 GLD） 或把黄金存在银行金库一样。
- 现状与未来 ：随着BlackRock（贝莱德） 、Fidelity（富达）等巨头的比特币现货 ETF 成为主流，未来 90% 的普通散户和基民，买卖的其实是金融机构账面上的比特币份额。
- 成本 ：机构内部的买卖只是数据库里数字的变动，完全不需要发生链上交易 ，因此交易成本取决于证券交易所的佣金，与比特币本身的 Gas 费毫无关系。
城市与房地产的演进（空间到达限度）
为什么大城市的房价和写字楼越来越高？这也是一种 L1 到 L2 的映射。
- Layer 1（土地限度） ：市中心（如纽约曼哈顿或北京国贸）的土地面积是绝对有限的，这就好比比特币 2100 万的总量。
- Layer 2（垂直扩容） ：当地皮贵到普通人根本买不起一整块地时，解决方式不是把地分碎（碎地没法盖房子），而是向上盖 100 层的摩天大楼 。每一层、每一个房间，其实就是这块土地的"Layer 2 分片"。你买的不是土地本身，而是土地之上的空间使用权。
- 互联网与算力的演进（带宽与性能限度）
您日常使用的互联网，底层也是这个逻辑。
- Layer 1（底层硬件）：全球光缆和数据中心的物理带宽、服务器的 CPU 算力是有极限的。如果几亿人同时去原生的服务器上读写数据，网络瞬间瘫痪。
- Layer 2（应用与缓存） ：互联网发明了 CDN（内容分发网络） 、边缘计算和各种缓存（Cache）。你刷短视频、看网页时，访问的其实是离你最近的"镜像和缓存层"（L2），只有极少数核心数据才回传到真正的中央数据库（L1）。
- Layer 1（实体企业）：像Apple（苹果） 、NVIDIA（英伟达） 这样的公司，普通人不可能跑去工厂买下一台光刻机或一条生产线，因为门槛和管理成本太高。
- ETF / 凭证化（股票）：华尔街把这些复杂的公司实体和资产打包，切分成无数个小股份（股票、或者追踪科技股的 ETF，如 QQQ）。你只需要在手机上点一下，就能享受它增长的红利。
- 金融方案（ETF/信托） ：由大机构把它锁死在底层，然后在上层发售门槛极低的"影子凭证"让大众参与。
ETF 的全称是 Exchange-Traded Fund 。
中文通常翻译为： 交易所交易基金 或 上市开放式基金 。