在游戏代练赛道，SaaS代练系统与独立护航小程序的竞争，核心是商业模式与技术架构的底层差异，二者适配不同规模从业者，源码实现逻辑也随之不同，共同构成行业两大主流解决方案。

底层逻辑上，SaaS代练系统以“租赁服务”为核心，主打轻门槛、标准化，本质是通过持续收取年费和订单抽成盈利，核心逻辑是服务规模化复用，用户无需投入开发成本，却需依附平台，数据与运营自主权受限。独立护航小程序则以“自主可控”为核心，采用买断式部署，一次性投入后无后续抽成，核心逻辑是打造专属品牌，掌控客户数据与运营规则，适配中小工作室长期盈利需求。

源码实现方面，SaaS系统采用UniApp ThinkPHP6架构，侧重多端适配与集中管控，核心模块含订单管理、多角色权限分配，通过Redis缓存与读写分离支撑高并发，源码需预留增值功能接口适配分层付费模式。独立小程序源码同样基于UniApp PHP开发，侧重轻量化与自主部署，简化平台管控模块，强化客户留存与自定义功能，集成WebSocket实现进度实时推送，部署后仅需承担服务器与域名成本。

二者无绝对优劣，SaaS适合新手快速起步，独立小程序适合追求长期盈利、注重品牌建设的从业者，源码实现需贴合其商业模式核心，平衡成本与自主可控性。

前言

本文分享如何在uniapp vue3 实现自定义微信小程序 tabBar。

配置信息

在 pages.json 中添加 tabBar 的相关配置，例如

{  
  "pages": [  
    {  
      "path": "pages/index/index",  
      "style": {  
        "navigationBarTitleText": "首页"  
      }  
    },  
    {  
      "path": "pages/mine/index",  
      "style": {  
        "navigationBarTitleText": "我的"  
      }  
    }  
  ],  
  "tabBar": {  
    "custom": true,  
    "color": "#7A7E83",  
    "selectedColor": "#3cc51f",  
    "borderStyle": "black",  
    "backgroundColor": "#ffffff",  
    "list": [  
      {  
        "pagePath": "pages/index/index",  
        "iconPath": "static/icon_component.png",  
        "selectedIconPath": "static/icon_component_HL.png",  
        "text": "首页"  
      },  
      {  
        "pagePath": "pages/mine/index",  
        "iconPath": "static/icon_API.png",  
        "selectedIconPath": "static/icon_API_HL.png",  
        "text": "我的"  
      }  
    ]  
  }  
}

添加 tabBar 代码文件

在根目录添加 custom-tab-bar 文件夹，下面包含微信小程序原生文件

编写 tabBar 代码

这一步需要获取自定义 tabBar 组件实例，通过示例来更新选中的 tab，微信小程序可以通过 this 操作，uniapp 也支持直接操作微信小程序组件示例，如下代码

<template>  
  <view>  
    <text>首页</text>  
  </view>  
</template>  

<script setup>  
import { getCurrentInstance } from "vue";  
import { onShow } from "@dcloudio/uni-app";  

const instance = getCurrentInstance();  

onShow(() => {  
  const tabBar = instance?.proxy?.$scope?.getTabBar?.();  // 获取组件示例函数返回值  
  if (tabBar) {  
    tabBar.setData({  
      selected: 0,  
    });  
  }  
});  
</script>

其他 tab 页同理

示例项目

参考附件

App如何隐藏手机底部安全边界问题（指示条、手机导航）

纯血鸿蒙（app-harmony）如何隐藏安全边界：

在 manifest.json 的 app-harmony 节点下独立配置：

"app-harmony": {    
  "safearea": {    
    "bottom": {    
      "offset": "none"    
    }    
  }    
}

苹果系统（IOS）如何隐藏安全边界：

在 manifest.json 的 app-plus 节点下配置：

"app-plus": {    
  "safearea": {    
    "bottom": {    
      "offset": "none"  // 设置为 none 可关闭底部安全区域占位    
    }    
  }    
}

注：IOS隐藏安全边界配置完后一定得重新云打包自定义基座才生效

安卓系统（）如何隐藏安全边界：

在第一个界面或随便一个界面script中设置。

// #ifdef APP-PLUS  
    // 判断当前环境是否为Android  
    if (plus.os.name.toLowerCase() === 'android') {  
        var Color = plus.android.importClass("android.graphics.Color");  
        const Window = plus.android.importClass("android.view.Window");  
        var mainActivity = plus.android.runtimeMainActivity();  
        var window_android = mainActivity.getWindow();  
        var WindowManager = plus.android.importClass("android.view.WindowManager");  
        var View = plus.android.importClass("android.view.View");  
        //直接隐藏    
        window_android.setFlags(Window.FLAG_FULLSCREEN, Window.FLAG_FULLSCREEN);  
        window_android.getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_FULLSCREEN | View  
            .SYSTEM_UI_FLAG_HIDE_NAVIGATION | View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY);  
        //设置为全透明    
        window_android.addFlags(WindowManager.LayoutParams.FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS);  
        window_android.setNavigationBarColor(Color.TRANSPARENT);  
    }  
// #endif

注：涉及原生安卓代码，有不懂的直接让AI解析
安卓隐藏安全边界 原文链接：https://blog.csdn.net/sct_123/article/details/142408327

希望可以帮助到你

【年轻创业者破局利器：全场景陪玩平台源码，智能里程计费+高并发架构，7天极速上线】

在陪玩经济从线上游戏延伸至线下社交的浪潮中，一款专为创业者打造的「全场景陪玩系统」震撼上线！系统深度融合LBS定位与动态计费算法，支持线上语音陪玩、线下电竞开黑、主题派对组局等多元场景，独创「智能里程核算引擎」彻底解决线下见面费用分摊难题，配合高并发架构与全开源代码，助力创业者快速切入千亿级社交娱乐市场。

🔥 三大核心优势，重新定义陪玩平台标准
AI里程计费系统
系统集成高德/腾讯地图实时导航API，用户发起线下邀约时自动规划最优路线，支持驾车、公交、骑行、步行四种模式智能切换。独创「动态计价模型」可自定义设置：
基础里程费（如每公里3元）
时段溢价（高峰期+20%）
拼车折扣（3人同行享7折）
特殊场景加收（如电竞酒店场地费）
所有费用自动生成电子账单，支持AA制或主客分摊，彻底告别线下见面"算不清账"的尴尬。
企业级高并发架构
采用PHP+Swoole协程框架重构核心服务，单服务器支持5万+并发连接，配合Redis缓存与MySQL分库分表策略，轻松应对周末高峰时段流量冲击。系统内置负载均衡模块，可无缝扩展至多机集群，满足区域性陪玩平台向全国扩张的需求。
全栈开源二开自由
交付完整源码包（含前端Vue组件+后端Laravel API+数据库设计文档），核心模块无任何加密，支持深度二次开发：
扩展剧本杀、飞盘等新兴社交场景
对接美团/抖音本地生活服务
开发企业版陪玩管理系统
集成AI语音识别实现实时互动质检
💡 技术实现示例（PHP里程计费核心逻辑）
🚀 为什么选择我们？
极速部署：提供Docker一键安装包，30分钟完成环境搭建
商业闭环：内置支付分账、邀请裂变、会员体系等盈利模块
持续更新：每月推送新游戏接口与防封机制升级
生态支持：加入创业者联盟共享百万级用户流量池

开发APP专用直播间页面:room.nvue (原生渲染（nvue）环境下开发布局开发)，组件LivePusherDemo.nvue。报错

经过测试，发现<live-pusher>，写在页面room.nvue页面文件里正常，写在LivePusherDemo.nvue组件里就会报错，此问题已经2天了，我还没有解决好。
运行报下面的错：
20:08:43.587 [Vue warn]: Unhandled error during execution of native event handler
at <LivePusherDemokey=0ref="livePusherDemo">
at <RoompageId=4pagePath="pages/live/room"__pageQuery={"roomnumber":"666"}>
20:08:43.588 TypeError: Cannot read property 'meta' of undefined

下面是ai给出的原因，及解决方案：
具体原因拆解
live-pusher 是原生组件，不是 Vue 组件。它的 @statechange、@netstatus、@error 事件由原生层（Weex/Android/iOS）触发，不经过 Vue 的事件系统。

事件参数格式差异。在页面中，原生事件回调时 e 对象的格式是 { detail: { code: xxx, ... } }，所以 e.detail 能正常解构。但在子组件中，由于 Weex 的事件传递机制不同，e 的格式可能变成了 { meta: { ... } } 或其他格式，导致 e.detail 为 undefined，然后 const { code } = e.detail 解构报错 Cannot read property 'meta' of undefined。

注意：错误信息中的 'meta' 字眼说明底层 Weex 在处理事件时使用了 meta 对象来包装事件数据，而 Vue 组件期望的是 detail 格式。

createLivePusherContext 在组件中创建的 context 内部引用的组件实例路径不对。在子组件中，原生层通过 this 回调事件时，可能无法正确找到 Vue 组件实例上的方法，或者事件的参数在传递过程中发生了格式丢失/变化。

为什么页面里正常、组件里就报错？
这本质上是 uni-app 在 nvue 中对原生组件（live-pusher、live-player）的组件化封装存在已知限制：

live-pusher 在页面（.nvue）中直接使用时，this 指向页面，原生事件回调路径是 原生层 -> 页面实例 -> 方法，格式正确。
live-pusher 被包在子组件中时，this 指向组件实例，原生事件回调路径变成了 原生层 -> 组件实例 -> 方法，但中间的 Weex 桥接层没有正确转换事件格式，导致 e.detail 丢失。

解决思路
有以下几种方向，你可以选择：

方案 A：放弃组件化封装（推荐，最稳妥） 将 live-pusher 直接写在 room.nvue 页面中，不封装成子组件。是 uni-app 官方推荐的做法。可以拆分出一部分逻辑（如配置管理、UI 弹窗）为普通子组件，但 live-pusher 标签本身必须保留在页面根模板中。

方案 B：事件处理加防御 + 手动适配事件格式 在组件的事件处理方法中，不直接解构 e.detail，而是做防御性判断，同时打印完整的 e 对象来确定实际格式：

方案 C：在 room.nvue 页面中创建 context，通过 props/emit 传递给子组件 让 live-pusher 的 id 暴露在页面上（不封装到子组件），在 room.nvue 的 onReady 中创建 context，然后通过 ref 调用子组件方法传递 context。这样可以避免子组件中 this 指向的问题。

总结：这是一个 uni-app nvue 环境下原生组件事件桥接的已知兼容性问题，不是你的代码逻辑错误。最简单的解决方式是将 <live-pusher> 标签直接放在 room.nvue 页面模板中，不要封装到 LivePusherDemo 子组件内。

【最终解决方案是】

将<live-pusher>写在页面里，设置开播的参数写在组件里，测试通过。
代码在下面的项目里可以查看。
直播间页面：/pages/live/room.nvue
主播设置开播参数：/pages/live/components_app/LivePusherApp.nvue
推流demo可以参考:/pages/video/push_app2.nvue

本项目前端代码已正式开源，旨在为开发者提供一套可参考的直播系统实现方案。欢迎各位同仁查阅源码、交流技术或将其作为二次开发的基础。

DCloud 插件市场**
便于直接在 HBuilderX 中导入使用：
点击查看插件详情 https://ext.dcloud.net.cn/plugin?id=26606

Gitee 代码仓库**
获取完整源代码及提交历史：
访问仓库地址 https://gitee.com/mldxmy/simplelive

1. 项目背景与技术选型

近期启动了一个基于 UniApp 的直播系统开发项目。在明确需求后，迅速完成了技术栈选型并投入开发。整体架构旨在实现一套代码多端运行（H5、微信小程序、APP），涵盖首页、直播列表、个人中心等核心模块。

• 前端框架：UniApp
• 后端管理：FastAdmin
• 即时通讯(聊天服务)：Workerman
• 目标平台：H5、微信小程序、原生 APP

2. 核心挑战与解决方案

虽然整体功能开发进展顺利，但在直播间页面的多端适配过程中遇到了三个关键技术瓶颈。以下是具体问题及最终的解决策略：

🔴 问题一：H5 端播放卡顿

• 现象描述：
  在 H5 端调试时，进入直播间页面加载极慢，体验严重卡顿。
• 原因分析：
  经排查，问题源于引用的第三方库 [hls.min.js]。该文件通过外网 CDN 引入，受网络波动影响较大，导致资源加载阻塞。
• ✅ 解决方案：
  本地化部署。将 [hls.min.js] 下载至项目本地目录，改为本地引用。此举显著提升了加载速度，彻底解决了卡顿问题。

  注：H5 端采用 m3u8 (HLS) 格式流，小程序端采用 rtmp 格式流。

🔴 问题二：APP 端页面层级错乱

• 现象描述：
  H5 和小程序端运行正常，但打包至 APP 端时，直播间页面布局完全错乱，视频组件覆盖异常。
• 原因分析：
  查阅文档后发现，这是由原生 APP 中视频组件的层级（Z-Index）导致的。试图在单一的 [.vue] 文件中通过条件编译兼容所有端（H5/小程序/APP）的方案，在处理复杂视频层级时存在天然局限。即便借助 AI 辅助调试三天，仍无法完美解决。
• ✅ 解决方案：
  拆分代码策略。放弃“一套代码通吃”的执念，改为维护两套直播间代码：
  1. [.vue] 文件：专用于 H5 和微信小程序。
  2. [.nvue]) 文件：专用于原生 APP（利用其原生渲染优势解决层级问题）。

🔴 问题三：APP 端推流功能实现困难

• 现象描述：
  由于 H5 限制及微信小程序政策调整（不再开放主播推流权限），推流功能仅在 APP 端有实际需求。在完成 [nvue]) 页面基础功能后，尝试利用 AI 生成推流逻辑，耗时两天仍未成功，且导致代码逻辑混乱。
• 原因分析：
  直播推流涉及底层摄像头权限、编码参数及推流协议，逻辑复杂度较高。完全依赖 AI 生成复杂业务逻辑容易导致代码结构不可控，维护成本激增。
• ✅ 解决方案：
  模块化隔离开发。
  1. 单独开发一个仅包含推流功能的独立页面，确保核心逻辑纯净可用。
  2. 验证成功后，再将该功能模块移植整合到主直播间页面中。

     💡 经验总结：对于高复杂度的底层功能，AI 可作为辅助参考，但核心逻辑仍需人工把控，避免过度依赖导致代码失控。

3. 总结

本次开发经历表明，在跨端直播场景下，"因地制宜"比“强行统一”更有效。针对视频播放和推流等特殊场景，灵活采用 [.vue] 与 [.nvue] 分离的策略，以及模块化开发思路，是保障项目稳定落地的关键。

本项目前端代码已正式开源，旨在为开发者提供一套可参考的直播系统实现方案。欢迎各位同仁查阅源码、交流技术或将其作为二次开发的基础。

DCloud 插件市场**
便于直接在 HBuilderX 中导入使用：
点击查看插件详情 https://ext.dcloud.net.cn/plugin?id=26606

Gitee 代码仓库**
获取完整源代码及提交历史：
访问仓库地址 https://gitee.com/mldxmy/simplelive

蓝牙搜索与设备发现是蓝牙操作的首要需求，下面是常见的封装实现：先启动搜索，再监听发现设备

uni.startBluetoothDevicesDiscovery({  
    allowDuplicatesKey: true,  
    success: () => {  
        uni.onBluetoothDeviceFound(res => {  
            console.log("startYasee =>", res);  
        });  
    }  
});

上面可以打开搜索，并发现设备，不过这个有个比较坑的地方，当stopBluetoothDevicesDiscovery停止搜索时，由于没有关闭监听uni.onBluetoothDeviceFound的API，导致这个设备发现监听一直在内存中运行。可见一个帖子https://ask.dcloud.net.cn/question/183922

问题

1.多调用一次就多执行一次onBluetoothDeviceFound，从而多一次重复上报设备，而且上报时间是一样的，需要处理重复相同的上报，给程序带来处理压力

2.由于onBluetoothDeviceFound监听一直未关闭，多次监听在内存中导致程序占用过高，易导致程序卡顿。

解决方案

uni.onBluetoothDeviceFound只执行一次，通过uni.$emit和uni.$on实现发现的设备上报，下面是封装的实现

/**  
 * 开始搜寻蓝牙设备【核心】  
 * 此操作比较耗费系统资源，请在搜索并连接到设备后调用uni.stopBluetoothDevicesDiscovery方法停止搜索  
 * @param     {Object}       options      同官方配置选项  
 * @param     {Function}     callback     回调函数，设置则接收uni.onBluetoothDeviceFound发现设备  
 */  
export function start(options = {}, callback = () => {}) {  
    return new Promise((resolve, reject) => {  
        const discovery = function() {  
            return new Promise((resolve, reject) => {  
                options.allowDuplicatesKey = true; //是否允许重复上报同一设备,若未能获取advertisData则需要找开  
                options.success = res => {  
                    if (callback) {  
                        // uni.onBluetoothDeviceFound没有关闭监听API，所以使用uni.$emit和uni.$on来解决重复监听问题  
                        // uni.onBluetoothDeviceFound(res2 => callback(res2));  
                        found();  
                        uni.$off("bluetooth-device-found");  
                        uni.$on("bluetooth-device-found", res2 => callback(res2));  
                    }  
                    resolve(res);  
                };  
                options.fail = reject;  
                uni.startBluetoothDevicesDiscovery(options);  
            });  
        };  
        discovery().then(resolve).catch(reject);  
    });  
}  

// 通过uni.$emit和uni.$on来解决重复监听onBluetoothDeviceFound的问题  
let foundable = false;  
function found() {  
    if (!foundable) {  
        foundable = true;  
        uni.onBluetoothDeviceFound(res => uni.$emit("bluetooth-device-found", res));  
    }  
}

前言

在 5.04 版本之前的 uniapp 和 uniappx，小程序端不支持分包引用的 node_modules 依赖打包到分包中，这对于很多备受小程序主包体积超出困扰的开发者来说，显然不是一个好消息。为了解决这一问题，5.04 版本开始，hx项目或者 cli 项目支持分包引用的 node_modules 依赖打包到分包中。下面介绍下具体的操作步骤，附件是示例项目。

分包优化

首先，需要在 mainfest.json 指定小程序节点下添加如下配置，例如：

{  
  "mp-weixin": {  
         "optimization": {  
            "subPackages": true  
          }  
   }  
}

筛选分包用的依赖

这一步尤为重要，要先梳理出哪些依赖是分包用到的，哪些是主包用到的，以及你期望的主包分包产物引用关系。

我们举一个简单的例子，主包用到了 lodash-es 的 add 和 subtract 函数，分包 sub 用到了 lodash-es 的 multiply 函数，这种分包用到的内容主包没用，就可以考虑使用这种策略，把 分包 sub 用到的 lodash-es 的 multiply 函数打包到 分包 sub 下，我们来看下 5.04 版本之前的效果

首先是项目结构，参考附件一

打包的产物体积，参考附件二

可以看到，用到的 lodash-es 的三个函数都被打包到了主包的 vendor.js 文件中。下面我们看下 5.04 如何解决这种问题

首先进入到分包的根目录，创建一个 package.json 文件，这里写分包需要用到的依赖，然后安装依赖，参考附件三。

然后重新打包即可。

可以看到 分包 sub 根目录下面多了 vendor.js 文件，里面就是 lodash-es 的 multiply 函数，打包效果参考附件四和附件五

注意事项

• 该优化只对 vue3 项目生效
• 支持 uniapp 和 uniappx 的小程序项目
• 支持 hx 项目和 cli 项目，测试项目是 hx 项目，cli 项目同理
• 仅支持 node_modules 中的 js 相关文件，不支持其他文件
• 测试项目为附件六
• 5.04 是指 hx 的版本号，uniapp 对应的依赖版本为 3.0.0-5000420260318001

苹果协议更新了，需要登录账号同意协议更新。

1. https://appstoreconnect.apple.com/ 这个页面会有一个黄色的提示，提示协议需要更新，点击蓝色 查看 按钮进行跳转 到https://developer.apple.com/account
2. 弹窗 协议点击 确定即可

分享原文来自：https://www.yunedit.com/article/requiredcontract

新盛公司注册官网【——xs10671.com——】【——微xs1067199——】【——Q企鹅3494604671——】24小时在线客户第一步；打开相关平台APP或应程序加载进入；
第二步在登录/注册页面找到注册会员按钮并点击第三步进入注册界面后填写必要打个人信息如用户名；手机号码qq等第四步设置安全且易记的登录密码，

2026年，游戏市场持续升温，年创收超百亿的代练行业成为灵活就业与创业的新蓝海。从《三角洲行动》到《王者荣耀》，海量玩家的冲段、刷道具需求，让代练服务供不应求，但传统接单模式的痛点的也日益凸显——第三方平台抽成高达20%-50%，从业者利润被严重压缩，而个人散单又面临信任缺失、管理混乱的困境。此时，Uni-app ThinkPHP双架构源码的出现，为创业者打开了新大门，无需专业技术，快速搭建专属代练接单平台，轻松抢占行业红利。

这款双架构源码，精准契合代练行业的核心需求，兼顾高效开发与优质体验。后端ThinkPHP框架稳定强韧，自带完善的安全机制与高效的业务处理能力，可快速实现订单管理、代练资质审核、财务结算等核心功能，适配高并发场景，哪怕新赛季开服订单暴涨也能稳定运行，同时后续维护升级成本极低，无需专业技术团队值守。

前端Uni-app则实现了多端互通的便捷体验，一套代码可同步生成微信小程序、H5、手机APP，覆盖绝大多数用户的使用习惯，玩家可随时随地下单、查看代练进度，代练者可快速接单、更新服务状态，彻底摆脱传统QQ群、淘宝店的低效模式。更重要的是，源码支持自定义功能，可根据需求添加实时进度追踪、双向信用评价、多支付渠道等模块，打造差异化竞争优势，降低纠纷率，提升用户复购率。

相较于从零开发平台，这套源码最大的优势的是“省时、省力、省钱”。无需懂编程，一键部署，最快7天即可上线运营，省去数月开发周期与高额开发成本；零抽成模式让平台所有收益自主掌控，按每月100单、每单100元计算，一年可多赚数万元，随着平台规模扩大，利润空间不可限量。无论是个人创业者、代练工作室，还是想拓展业务的游戏从业者，都能借助这套源码快速入局。
查看演示及源码获取地址⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇⬇

dcloud社区排名前20；
npm上传的某个插件超2k+下载；

使用uniapp上架过小程序，app，h5
小程序平台：微信小程序、支付宝小程序
app平台：华为、小米、oppo、vivo、荣耀、ios

熟练使用uview、element ui、uv-ui、echarts、vant、websocket...

要求自研、全职、双休、五险一金

有的联系q：1814963581，备注来意