你这个问题本质上踩到了 ArkUI ForEach.onMove() 的一个设计限制：

只要挂了 onMove

拖拽排序能力开启

目前没有类似：

.enabled(false)
.disableMove(true)

这种官方 API。

也就是说：

onMove 存在
≠
可以动态关闭

而是：

onMove 存在
=
整个List进入可拖拽排序状态

这是框架行为。

你提到的几个方案为什么会出问题，我其实都遇到过。

方案1

.onMove((from,to)=>{
  if(!this.enableMove){
    return
  }
})

看起来合理。

实际上：

拖拽已经发生
只是数据没改

所以：

UI排序动画
和
数据源
不同步

然后就开始抽风。

这个方案确实不可用。

方案2

.onMove(
  this.enableMove
    ? (from,to)=>{}
    : undefined
)

或者：

condition ? handler : null

ArkUI Diff 有概率出现：

事件节点残留

尤其：

List
ForEach
onMove

组合下很容易出现：

拖拽状态机没重建

于是就会出现：

一会能拖
一会不能拖

那种非常诡异的现象。

方案3

两个 ForEach

if(enable){
  ForEach(...).onMove(...)
}else{
  ForEach(...)
}

理论正确。

实际上：

组件树重建

成本太大。

数据复杂时：

滚动位置丢失
焦点丢失
动画重置

所以你不接受很正常。

真正比较靠谱的方案

方案A

控制 ListItem 是否响应长按

例如：

ListItem() {
 ...
}
.gesture(
  this.enableMove
    ? LongPressGesture()
    : TapGesture()
)

或者：

.enabled(this.enableMove)

从源头阻断拖拽触发。

方案B（推荐）

使用 API20+ 的新版：

.onMove(handler,eventHandler)

官方新增了：

ItemDragEventHandler

可以控制拖拽过程。

例如：

.onMove(
  this.moveHandler,
  {
    onItemDragStart: () => {
      return this.enableMove
    }
  }
)

如果你的项目已经是：

API20+
HarmonyOS 6.1

建议直接研究这个方向。

比老版 onMove 好很多。

方案C（很多项目最终这么干）

不要依赖：

ForEach.onMove

直接自己实现排序。

即：

PanGesture
+
拖拽浮层
+
数据交换

虽然代码多。

但：

可控
稳定
支持动态开关
支持权限控制
支持复杂动画

很多 IDE 文件排序、

音乐播放列表排序、

看板拖拽

最后都放弃了官方 onMove。

你提到的泛型问题

这个：

struct ListView<T>

确实不支持。

ArkTS UI 组件：

struct

目前不能像 TS 那样写泛型组件。

所以：

Array<any>

或者：

Object[]

经常会导致：

状态系统推导失败

这也是很多人吐槽的点。

通常会改：

@Observed
class ItemModel

然后：

Array<ItemModel>

来绕过。

所以结合你描述：

需要动态控制是否允许拖拽
不能重建ForEach
不能接受UI状态错乱

我建议直接放弃：

onMove里return

和：

三元切handler

这两个方案。

目前最稳的是：

从拖拽触发源阻断

或者：

自己实现拖拽排序

因为 ArkUI 当前的 ForEach.onMove() 本身就不是按照“可动态启停排序能力”设计的。

直接用draggable 属性，是可以直接禁用单个 item 拖拽的。

类似这样

ForEach(this.data, item => {
  ListItem() {
    Text(item)
  }
  .draggable(!this.enableDrag) // 控制是否可拖拽
})
.onMove((from, to) => {
  if (!this.enableDrag) return; 
  // 排序逻辑
})

可以直接阻止手势识别，但 onMove 回调还在