网狐电玩平台大厅银行去除手机短信验证码校验（Lua 技术)

在网狐系列电玩平台中，大厅“银行”功能默认对接了阿里云短信验证码逻辑。只要账号未绑定手机号，点击银行入口就会被强制拦截，弹出“需要绑定手机才能使用银行功能”的提示。

在一些本地测试环境、纯功能调试环境或不启用短信体系的部署场景下，这个校验反而会成为阻碍。本文从源码层面出发，完整讲清楚银行拦截的触发逻辑，并给出稳定、安全、低风险的修改方案。

触发问题的根源在哪里

问题并不在服务端，而是在大厅客户端的 Lua 逻辑中。

银行入口的校验代码位于大厅资源包中，属于前端逻辑拦截，只要条件满足，就不会进入真正的银行界面。

相关文件路径如下：

/assets/base/res/client.zip

解压后定位到：

/client/src/plaza/views/ClientScene.lua

在该文件中可以找到以下函数：

function ClientScene:addBankLayer()

这里正是大厅点击“银行”时的入口函数。

原始逻辑分析（为什么会弹绑定手机）

原始代码中，通常存在如下判断（行号可能因版本略有差异）：

function ClientScene:addBankLayer()

if not yl.CUSTOM_TEST 
   and (not GlobalUserItem.szBindMobile or GlobalUserItem.szBindMobile == "") then

    QueryDialog:create(
        "您需要绑定手机，才能使用银行功能，点击“确定”进行绑定。",
        function(ok)
            -- 跳转绑定逻辑
        end
    )
    return
end

-- 正常进入银行的逻辑

这里的关键点有三个：

• yl.CUSTOM_TEST
  用于区分测试环境与正式环境
• GlobalUserItem.szBindMobile
  当前用户是否已绑定手机号
• return
  一旦触发判断，直接中断银行入口

只要用户没有绑定手机号，并且不是测试环境，就一定会被拦截。

常见错误改法说明（很多人会踩坑）

不少人尝试“改条件”来绕过验证，例如写成：

if yl.CUSTOM_TEST and (GlobalUserItem.szBindMobile or GlobalUserItem.szBindMobile == "") then

这种写法在 Lua 中是有问题的。

原因在于 Lua 的 or 表达式并不是布尔判断，而是“返回第一个为真的值”。
只要 GlobalUserItem.szBindMobile 是非空字符串，整个条件就直接成立，反而更容易出现逻辑异常。

结论一句话：
不要试图靠复杂判断改逻辑，容易反向触发。

稳定做法：直接关闭绑定校验（推荐）

最稳、最干净的方式，是直接跳过这段校验逻辑，不改动后续银行代码。

只需要在 ClientScene:addBankLayer() 中，将拦截逻辑注释或失效即可。

示例如下：

function ClientScene:addBankLayer()

-- 关闭银行的手机号绑定校验
-- 原逻辑如下：
-- if not yl.CUSTOM_TEST 
--    and (not GlobalUserItem.szBindMobile or GlobalUserItem.szBindMobile == "") then
--     QueryDialog:create("您需要绑定手机，才能使用银行功能，点击“确定”进行绑定。", function(ok)
--     end)
--     return
-- end

-- 下面保持原文件中的银行打开逻辑不变

这种方式的特点：

• 不依赖 yl.CUSTOM_TEST
• 不关心手机号字段状态
• 不影响银行内部逻辑
• 不引入新的分支风险

极简写法：让条件永远不成立

如果你不想注释多行代码，也可以使用最简单的方式：

function ClientScene:addBankLayer()

if false then
    QueryDialog:create("您需要绑定手机，才能使用银行功能，点击“确定”进行绑定。", function(ok)
    end)
    return
end

-- 银行逻辑正常执行

这属于“明确关闭功能”的写法，阅读成本低，也不容易被后期维护误解。

修改完成后的注意事项

修改完成后，记得以下几点：

• 修改的是 client.zip 内的 Lua 源码
• 修改完成需要：
  • 重新压缩 client.zip
  • 覆盖原资源包
• 若项目存在：
  • 热更新
  • Lua 编译（.luac）

  需要按项目原本的流程重新生成资源

适用场景说明

该修改适用于以下情况：

• 本地测试 / 内网测试
• 不启用短信体系的环境
• 仅做功能演示或技术研究
• 已通过其他方式保证账户安全

如果你本身还需要短信体系，但不想在测试阶段强制绑定，也可以再做一层环境变量开关控制，这类属于二次优化，逻辑思路是一样的。

大厅银行是否必须绑定手机，本质只是一个 Lua 前端判断，并非不可控的系统级限制。
相比“硬改条件”，直接关闭拦截逻辑才是：

• 可控的
• 可维护的
• 不易出错的

如果你后续还需要处理 绑定入口隐藏、短信模块整体剥离、银行入口改写 等情况，可以在此基础上继续拆解，不会影响主流程。

需要我帮你把这一套改法整理成 补丁文件结构 或 热更用差异包，也可以直接说你的版本环境。