解析总量 parse
0次
▲ 12.4%较上周期
Overview
运行概览
小程序四条产品线（解析 / 聊天 / 在线用户 / 3D 魔方）的整体运行水位、接口热度和 7 日趋势。
演示数据。字段名与枚举值取自真实代码（server/wxService.js、
utils/logger.js、pages/parseLog/），数值为样例，接后端时替换数据源即可。
运行健康度
7 段对应项目真实子系统。任一段转为警戒/异常时，优先看对应的源码模块。
—分 / 100
解析成功率
0%
失败 700 次·超时占 62%
订单金额 pay
¥0
成功 214 单·未完成 37 单
在线设备
0
企业微信 11 台
接口调用热度
后端 body.type 分发分支，共 34 个；下列为 Top 8。
解析趋势
按平台拆分 · 近 7 日
Parse
解析记录
只统计事件名 === parse 的日志条目（取自前端请求行的请求体 type）。
可按用户过滤（选用户后改读该用户自己的日志 wx:app:logs:<openid>，与「日志与链路」页同源）；
右侧「刷新」只重取本页，不牵连整站其它端点。
平台徽标由关键词匹配得出；解析历史 URL 本体存于小程序本地 storage。
历史链接
—
| 平台 | 用户 | 域名 | 链接 | 解析时间 | 耗时 | 状态 | 详情 |
|---|
—
Orders
虚拟支付订单
订单来自 MySQL wx_vpay_orders，与小程序 /pay event=order_list 同一张表、同一份字段契约。
状态字段兼容字符串与 0–4 数字，此处按 normStatus() 归一化展示。
按用户过滤会把 openid 发到后端在 SQL 里筛 —— 不是对已取回的行做前端 filter，
否则会漏掉那个用户更早、已经掉出取数上限的订单。
订单明细
—
| 订单号 | 用户 | 商品 | 类型 | 数量 | 金额 | 状态 | 下单时间 | 支付时间 |
|---|
—
Scan
扫码记录
小程序「更多功能 → 扫一扫」成功后的原始结果：经 WebSocket 以
{ type:"scan", content, scanType, charSet } 上报，后端原样写入 Redis
wx:scan:log。本页只读 —— 不解析、不改写、不裁剪。
后端只存 openid，所以「用户」列的昵称与头像是前端从在线快照里补齐的；
content 一律原文透出，点「详情」看完整内容与全部字段。
扫码明细
—
| 类型 | 用户 | 内容 | 长度 | 扫码时间 | 详情 |
|---|
—
Permissions
用户与权限
页面 → 权限位映射。以后端 global.APP_CONFIG 的 perm.pages 为唯一来源，
小程序由 PAGE_PERMISSION 下发、本地 PAGE_PERMISSION_MAP 兜底。
本页所有字段均可直接编辑，保存后业务节点在下一条消息即生效。
配置来源
运行时配置整体替换本地兜底表
- 当前生效来源
- 后端 APP_CONFIG · perm.pages
- 本地兜底
- PAGE_PERMISSION_MAP
- 静默窗口
- 60 000 ms
- 最近成功拉取
- —
- 缓存键
- PERMISSION_CONFIG
- 登记页面数
- —
拉取在途有
_permCfgLoading 防并发；成功后进入 60s 静默窗口，
窗口内的广播风暴与反复进出页面不会重复请求。改了本页配置后，后端会主动广播
permission_config_updated，小程序立刻强制重拉 —— 不必等静默窗口过期。
越权提示文案
全站统一，改完保存即全站生效；正文支持换行
越权弹窗 · 标题
越权弹窗 · 正文
无权限弹窗 · 标题
无权限弹窗 · 正文
两段文案分别对应后端
perm.revokedTitle/Content 与
perm.noPermTitle/Content，下发字段 PERM_REVOKED_* /
PERM_NO_PERM_*，小程序侧留空即回落到自身兜底文案。
聚合入口页（
morefeatures）不整体拦截，逐项在页面内自行校验；
PermissionManagement / virtualpay / payorders 属管理或支付流程，不做权限位拦截。
页面 × 权限位 矩阵
点格子即把该页面的权限位切成这一列；标题与路径可直接改。
列头显示的中文名可以随便改，title 里的字段名须与后端 permisionsList 的 key 逐字一致（不可改）。
与后端一致
权限位中文名
控制台与小程序「权限管理」页的显示名。name 是提交给后端的字段名，
改了等于把该权限位静默清零，所以这里只让改中文名。
与后端一致
小程序在线用户 · 权限下发
勾选后点「保存」→ 入队 → wxService 应用并递增 permRc（旧离线票据立即作废）
—
—
Devices
设备与运行环境
系统信息统一由 utils/windowInfo.js 提供：模块加载期探测一次并冻结缓存，避免监听器累积。
当前设备
来自 getSystemInfo() 的合并结果
统一入口：三出口
调用方只认这三类出口，不再各自读 API
DEVICE
WINDOW
APP_BASE
SETTING
① 缓存出口 · Object.freeze
② 新鲜出口 · getFreshTheme()
③ 环境出口 · getEnvironment()
调用方：app.js / app.global.js / platform.js / wxService.js
SETTING 片故意不回落旧 API。旧
getSystemInfoSync 返回全字段对象，
若并入会在 device → window → base → setting 合并时覆盖前三片已取到的细分字段；
同时会让「有细分 API 时绝不调旧 API」的设计目标失效。
environment 仅由旧 getSystemInfoSync 返回，四件套细分 API 均不含它 ——
因此企业微信识别必须走 getEnvironment()，且只取值不判断，
=== 'wxwork' 的比较留在 platform.js。
端分布
请求头 sys.environment 随签名一起上报，后端据此区分请求来源端
Logs & Trace
日志与登录链路
日志上报配置在本页直接改，改动写入 Node-RED global.APP_CONFIG，
业务节点在下一条消息即生效；登录链路追踪记录从 doLogin 到凭证落库的每个关键节点。
上报配置
改动写入
global.APP_CONFIG，业务节点下一条消息就读到新值。
但生效时机分两类：log.ttlSec / maxGlobalCount / maxUserCount
/ traceMax 是后端写 Redis 时用的，保存后下一次写日志即按新值裁剪；
而 log.defaultConfig.* / reportLevel / adminReportLevel
是 get_logger_config 的下发值，
要等小程序下次调用该接口（冷启动 / 重进小程序）才拿到 —— 保存成功 ≠ 已下发到客户端。
级别分布
仅 reportLevel 白名单内的级别进入上报队列
连续失败达 5 次后进入 60s 冷却，
期间不再发起上报，避免后端不可达时形成请求雪崩。冷却到期由下一次
pushRemote 触发恢复。
这两个阈值是 logger.js 里的代码常量（FAIL_THRESHOLD /
PAUSE_MS），不在上面的可配项里，改它们要改源码。
日志流
不选用户 = 全局日志（wx:app:logs）；选用户 = 该用户日志（wx:app:logs:<openid>）。
内容列放不下整行日志，点行末「详情」看该条的完整原文与全部字段。
| 级别 | 内容 | 时间 | 详情 |
|---|
—
登录链路追踪
冷启动失败闭环：wx.login → 401 兜底 → reLogin → 补试
WebSocket
WS 调试台
直连后端 WebSocket（server/ws/wsService.js）：监听全部下行帧，
也能主动发送任意帧。刷新或关闭页面会销毁客户端 ——
停心跳 → 停重连 → 发 disconnect 让服务端立刻清会话 → 正常关闭。
连接设置
凭证只进本标签页的 sessionStorage，关标签即失效
主动发送
点任一指令填入模板；Ctrl+Enter 发送
事件流 0
后端 wsService 的全部下行帧，默认不过滤。缓冲上限 500 条（超出丢最旧）—— AI 流式回复是一 token 一帧，不限量会吃满内存。
| 时间 | 方向 | 类型 | 摘要 | 原文 |
|---|
Config
运行配置
后端 wxService.js / wsService.js 的可调参数集中在这里
（日志与上报参数已移到「日志与链路」页，在那边的「上报配置」里改）。
改动写入 Node-RED global.APP_CONFIG，业务节点在下一条消息就会读到新值 ——
不用重贴 function 节点、不用重启 Node-RED。
存储位置是 global，不是 flow。
这是复用后端既有约定：
flow 只放「同一条 flow 内共享的业务表」
（appidList / authUserSet / help_content / ws_sessions …），
global 放「全局开关 / 密钥 / 跨 tab 的运行时状态」
（ws_sign_mode / admin_openids / qlgq_appid / ADMIN_PASSWORD …）。
配置项属于后者，所以与 ws_sign_mode 完全同一套写法。