在app.vue里面写全局样式，为了避免样式污染，在你要的外面包一层div 做局部限制 .uni-input-input这个类名 是uni-app自动生成的类名 ，亲测有效

```
.login_box{
.uni-input-input{
border:1upx solid #f8f8f8;
border-radius: 10upx;
box-sizing: border-box;
&:focus{
background: #ebfff9;
border-color: #28b28b;
}
}
}
```

微信小程序上支持的是 wxss 后缀文件，在微信小程序中不支持 import url 语法，也不支持导入 css 文件。

此贴时间存在时间较久了，如果仍有问题，请开新贴解决。

##解决了
用
// #ifdef H5
js代码块
// #endif

文档看不懂？行吧！
下载我已经打包好的示例压缩包，解压后导入你的hx运行体验，已完美解决vuedraggable报错问题

这不是Bug，在小程序自定义组件中使用时，需要传递当前组件实例的。[文档](https://developers.weixin.qq.com/miniprogram/dev/api/canvas/wx.createCanvasContext.html)


在 options API 中就是 this

在 composition API 是使用 `getCurrentInstance()` 获取到的实例

针对问题中的代码给出的伪代码是：

```js
import { getCurrentInstance } from 'vue'
const instance = getCurrentInstance()
const drawContent = () => {
// ...
const ctx = uni.createCanvasContext('myCanvas', instance)
// ...
}
```

hbuilderx 4.41 修复了这个问题。

注意 , 在你的代码中 , 全局搜索有使用 getSystemInfo 或者 getSystemInfoSync 的地方 , 需要手动修改 , uniapp 框架中的已清除 , 新建项目不会出现这个警告

请使用 uni.getSystemSetting、uni.getAppAuthorizeSetting、uni.getDeviceInfo、uni.getWindowInfo、uni.getAppBaseInfo 代替

1. 通过cli创建vue3项目，必须用npx degit dcloudio/uni-preset-vue#vite my-vue3-project命令创建，详情：https://uniapp.dcloud.net.cn/quickstart-cli.html#%E5%88%9B%E5%BB%BAuni-app，vue2和vue3的cli命令不同，不能把一个使用vue2命令创建的项目通过修改manifest.json直接变成vue3.

2. HBuilderX创建的项目vue2和vue3运行的也是不同的编译器插件，不能用vue2的编译器(uniapp-cli)插件来运行vue3，vue3对应的编译器插件是(uniapp-cli-vite)

已提供uts插件解决此需求，请使用uts插件：[uni-requestMerchantTransfer](https://ext.dcloud.net.cn/plugin?id=22283)

更新：

HBuilderX alpha 4.54 已支持。

感谢反馈，我看下。问题已定位，感谢你的反馈，下个 Alpha 会修复。

如之前沟通，你发现引用了 encryptlong-telen 这个加密库，会导致 xhs 平台无法运行，微信小程序正常。经过我测试，是因为这个三方库中会尝试访问 navigator 参数，小红书中不存在。

这个你可以向三方库反馈，也可以临时兼容，比如在xhs 平台的 vendor.js 顶部添加下面类似的 mock 代码

```js
globalThis.navigator={appName:'xhs',userAgent:'xhs'}
```

解决方式很多，手动改，写 vite buildEnd 插件，或者修改三方库源码添加条件编译

```js
// #ifdef MP-XHS
globalThis.navigator={appName:'xhs',userAgent:'xhs'}
// #endif
```
都可以，这个你自行选择吧。

补充：
补充：小红书小程序环境不支持window，也建议代码改为 globalThis;
```js
try {
globalThis.window = globalThis;
} catch (error) {

}
```

这是一个设计取舍与风险控制问题。
群人数为500人时，个推一次即可完成推送；若为5000人，则需推送10次。当然，也可依据群成员活跃度，先推送给活跃成员，不活跃的稍后推送，如此即便人多，活跃者也能先收到，不活跃者晚几秒。大群需在设计上做出调整，若实际场景没必要，就别设置超大群。
再者是风险控制问题，在大群中，用户发布内容如果并不合适，一旦传播人数超500人，那风险的定性就会不同。因此，许多应用都将群人数限制在500人。

题外话：uni-im 有计划给群增加一个“休眠”的概念。如果用户连续 x 天不点开群聊，则此群将不再“实时”给此“休眠”用户推送消息。当下一次用户点开此群，才会重新激活。这种方案可以减少服务器压力和没必要的推送。

通了，总之很多坑，
1. uts修改可能热更新无效，需要重新运行，
2. uts可能编译失败了有报错但不会停止会被后面正常运行的日志淹了，
3. <view 不知道AI哪里学来的用法总之这个tag不行，
4. NVLoad是必须的，