1.首先开通支付宝云空间

1. 在hbuilderx里关联新的云空间
2. 上传全部云函数及database
   4.这时候，支付宝云空间的数据库是空表，先从阿里云的数据库选择导出，保存为export.json
3. 创建parse.js，内容如下

const fs = require('fs')
const path = require('path')
const readline = require('readline')

const cwd = process.cwd()
const inputPath = path.resolve(cwd, process.argv[2])
const outputPath = path.resolve(cwd, process.argv[3])

if (fs.existsSync(outputPath)) {
throw new Error(输出路径（${outputPath}）已存在)
}

function getType(val) {
return Object.prototype.toString.call(val).slice(8, -1).toLowerCase()
}
function parseRecord(obj) {
const type = getType(obj)
switch (type) {
case 'object':
if (obj.$oid) {
return obj.$oid
}
if (obj.$date) {
return obj.$date
}
const keys = Object.keys(obj)
for (let i = 0; i < keys.length; i++) {
const key = keys[i];
obj[key] = parseRecord(obj[key])
}
return obj
case 'array':
for (let i = 0; i < obj.length; i++) {
obj[i] = parseRecord(obj[i])
}
return obj
default:
return obj
}
}

async function parseCollection() {
const inputStream = fs.createReadStream(inputPath)
const outputStream = fs.createWriteStream(outputPath)

const rl = readline.createInterface({
input: inputStream
});

for await (const line of rl) {
const recordStr = line.trim()
if (!recordStr) {
continue
}
const record = parseRecord(JSON.parse(recordStr))
outputStream.write(JSON.stringify(record) + '\n')
}
rl.close()
console.log(处理后的文件已输出到${outputPath})
}

parseCollection()

6.将parse.js放到电脑上，比如E盘，创建data文件夹，将export.josn放进去，打开终端，输入指令 node E:\parse.js E:\data\export.json E:\data\output.json

7.将转好的数据导入到支付宝云对应的新表里

8.parse.js自行添加转换规则，以上只是简单示例，根据自己的表结构来

问题描述

在开发 APP 专用直播间页面时，遇到 <live-pusher> 组件在不同层级引用时的兼容性问题：

• 正常情况：将 <live-pusher> 直接写在页面文件 room.nvue 中，运行正常。
• 异常情况：将 <live-pusher> 封装在子组件 LivePusherDemo.nvue 中，运行报错。

该问题已困扰两天，经过排查与测试，确认为 UniApp nvue 环境下原生组件的已知限制。

报错信息

20:08:43.587 [Vue warn]: Unhandled error during execution of native event handler  
 at <LivePusherDemo key=0 ref="livePusherDemo">  
 at <Room __pageId=4 __pagePath="pages/live/room" __pageQuery={"roomnumber":"666"}>  
20:08:43.588 TypeError: Cannot read property 'meta' of undefined

原因分析

1. 原生组件特性

live-pusher 是原生组件（Native Component），而非标准的 Vue 组件。其事件（如 @statechange, @netstatus, @error）由原生层（Weex/Android/iOS）直接触发，不完全经过 Vue 的事件系统。

2. 事件参数格式差异

• 在页面中：原生事件回调时，事件对象 e 的格式通常为 { detail: { code: xxx, ... } }，因此 e.detail 可以正常解构。
• 在子组件中由于 Weex 桥接机制：事件传递路径变为 原生层 -> 组件实例 -> 方法。在此过程中，Weex 桥接层可能未正确转换事件格式，导致 e 的结构变为 { meta: { ... } } 或其他格式，使得 e.detail 为 undefined。
• 报错根源：代码中尝试执行 const { code } = e.detail 时，因 e.detail 不存在而抛出 Cannot read property 'meta' of undefined（底层使用 meta 包装数据，但 Vue 侧期望 detail）。

3. Context 创建问题

createLivePusherContext 在子组件中创建时，内部引用的组件实例路径可能不正确。原生层通过 this 回调事件时，可能无法正确找到 Vue 组件实例上的方法，或导致事件参数丢失。

解决思路

针对此兼容性问题，主要有以下三种解决方案：

方案 A：放弃组件化封装（推荐，最稳妥）

• 做法：将 <live-pusher> 标签直接写在 room.nvue 页面模板中，不将其封装为子组件。
• 依据：这是 UniApp 官方推荐的做法。
• 优化：可以将配置管理、UI 弹窗等非原生部分拆分为普通子组件，但核心推流标签必须保留在页面根模板中。

方案 B：事件处理加防御 + 手动适配

• 做法：在组件的事件处理方法中，不进行直接解构，而是先打印完整 e 对象以确定实际格式，并做防御性判断。
• 缺点：需要针对不同平台进行复杂的兼容性处理，维护成本高。

方案 C：页面创建 Context，传递给子组件

• 做法：让 <live-pusher> 的 id 暴露在页面上，在 room.nvue 的 onReady 中创建 context，再通过 props/emit 或 ref 传递给子组件。
• 缺点：架构较复杂，且仍可能受限于原生事件回调路径问题。

最终解决方案

采用 混合模式：将原生推流标签留在页面，将业务逻辑封装在组件。

1. 推流标签位置：将 <live-pusher> 直接写在页面 room.nvue 中。
2. 参数配置位置：将开播参数设置、业务逻辑封装在组件 LivePusherApp.nvue 中。
3. 结果：测试通过，运行稳定。

相关代码参考

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

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

资源链接

• 技术介绍: https://smplive.wpygo.com/
• 在线文档: https://www.showdoc.com.cn/smplive
• DCloud 插件市场:
  • 便于直接在 HBuilderX 中导入使用
  • 点击查看插件详情
• Gitee 代码仓库:
  • 获取完整源代码及提交历史
  • 访问仓库地址

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

客户那边好像是是用的openssl v3 https://app.liuyingyong.cn/build/errorLog/af981a00-24d7-11f1-8a69-45fd92a17fd0 这个是日志

vite8-deepseek-webai：最新前端技术栈vite8.0、vue3.5、arco-design、markdown、openai调用deepseek-v3.2聊天大模型。支持light+dark主题、深度思考、代码高亮复制代码/下载、katex公式、mermaid图表等功能。

项目技术知识

• 开发工具：vscode
• 前端框架：vite8.0+vue3.5.30+vue-router5.0.3
• 智能大模型：deepseek-v3.2 + openai
• 组件库：arco-design2.57.0
• 状态管理：pinia3.0.4
• markdown插件：markdown-it14.1.0
• 代码高亮插件：highlight.js11.11.1
• katex公式：plugin-katex0.25.1

项目结构目录

使用最新正式版vite8.0搭建项目，集成deepseek api大模型接口，vue3 setup语法编码开发。

vite8-vue3-webai网页版ai对话项目已经发布到我的原创作品集，欢迎下载使用哈！
Vite8+DeepSeek+Vue3.5搭建Web版AI智能聊天对话助理

如果对项目具体的实现感兴趣，可以看看下面这篇文章。
Vite8+DeepSeek网页版AI助手|vue3+arco本地web版ai流式打字问答系统

热文推荐

uniapp+deepseek流式ai助理|uniapp+vue3对接deepseek三端Ai问答模板
vite8.0+deepseek流式ai模板|vue3.5+vant4+markdown打字输出ai助手
tauri2.10+deepseek+vite7客户端ai系统|Tauri2+Vue3.5桌面AI程序Exe
electron39-vue3ai电脑端AI模板|electron39+deepseek+vite7聊天ai应用
Electron38-Vue3OS客户端OS系统|vite7+electron38+arco桌面os后台管理
Electron38-Wechat电脑端聊天|vite7+electron38仿微信桌面端聊天系统
electron38-admin桌面端后台|Electron38+Vue3+ElementPlus管理系统
最新版uniapp+vue3+uv-ui跨三端短视频+直播+聊天【H5+小程序+App端】
最新版uni-app+vue3+uv-ui跨三端仿微信app聊天应用【h5+小程序+app端】
Tauri2.9+Vue3桌面版OS系统|vite7+tauri2+arcoDesign电脑端os后台模板
Tauri2.8+Vue3聊天系统|vite7+tauri2+element-plus客户端仿微信聊天程序
Tauri2-Vite7Admin客户端管理后台|tauri2.9+vue3+element-plus后台系统
uniapp-vue3-os手机oa系统|uni-app+vue3跨三端os后台管理模板
Flutter3-MacOS桌面OS系统|flutter3.32+window_manager客户端OS模板
最新研发flutter3.27+bitsdojo_window+getx客户端仿微信聊天Exe应用
最新版Flutter3.32+Dart3.8跨平台仿微信app聊天界面|朋友圈

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

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

如何修复？是 bug 吗？

因使用过云打包服务，我们公司使用的是苹果企业证书，仅使用过HbuildX上传过苹果企业证书。过了没多久，就收到苹果冻结企业账号的邮件，说我们证书泄漏。

几经交涉后，账号得到恢复，并且苹果给出了泄漏的证书所打包的APP。

假如是使用mac电脑，可以使用xcode上传。也可以使用xcode的命令行工具来上传，

但是windows电脑没有xcode这些工具，也没有windows版本的xcode。不过安装xcode比较大，也比较麻烦，mac电脑假如没空间，也可以使用下面windows的方法来上传。

windows电脑发布ipa文件到苹果开发者中心的构建版本，就不能使用xcode，windows发布ipa到构建版本，可使用香蕉云编来上传。

下面，是windows电脑上传ipa的方法：
（1）打开香蕉云编，进入后台，使用上传ipa到app store的功能，点击上传新文件

（2）进入密钥或密码填写界面

这里可以使用app store密钥上传或者专用密码上传，这里建议使用app store密钥上传，更加专业和可靠，因为密钥永远不会失效。

（3）设置app store密钥
假如是第一次上传，还没有app store密钥，就需要先去app store先设置密钥，上传界面有设计密钥或专用密码的教程。

（4）上传ipa
填写完所有资料，最后一步，就是上传ipa了，上传过程大概一两分钟，就可以看到上传成功了。上传成功半小时后，留意苹果的邮件，看看有没有成功进入构建版本。

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

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

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

要求自研、全职、双休、五险一金；
地方：深圳、广州、福建地区这几个最好

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