content运行时肯定要计算，只需要计算时把他的初始坐标也作为其中一个计算变量考虑进去就可以了
现在 mask 也有个莫名其妙不生效的问题（跟scrollview没关系），原因正在找。。
mask 有没有重现的 demo ？
正的找。。。没定位问题。
缩放的时候不显示
不缩放的时候竟然mask一半生效，一半不生效。。。。
大佬好，你反馈的 Content 问题很有代表性，很感谢你对产品精益求精的态度。
方案一：如果允许自由设置 Content 的坐标，那么如果发生误操作，UI 就有可能产生一些意想不到的效果，比如拖不到顶部、或者内容被裁剪。
方案二：如果不允许自由设置 Contnet 坐标，那么就会牺牲一些自由度。例如你图中的边距，就不能通过 Mask 和 Content 组合而来。而是需要让 Mask 略小于 ScrollView（2.0 是允许的），或者在 Content 中再套一层节点。
我们也会希望让产品更加“智能”、符合直觉，不过 Creator 毕竟不是自研引擎，很多人用的时候难免会遇到各种行行色色的用法，特别是多人配合时，难免由于小白的加入引发一些低级错误。因此“避免用错”也是我们比较看重的一点，毕竟用错的话，很会浪费用户的研发时间，我们的技术支持也没有足够的人力去照顾好这类问题。
因此，我们更倾向于第二种方案，目标是 确保编辑器和预览时效果一致，不论用户如何操作。保留用户实现自定义效果的可能性，哪怕这样会麻烦一点。 不知道这样的逻辑你是否能接受。
谢谢
（Mask 问题如果需要的话可以再开一帖）
1赞
老实说现在的实现确实还是会有点复杂，不过我们没有找到更合适的方案。或许之后我们可以参考一下同类引擎的其它做法。
谢谢这么认真的回复。
我也 反对 运行时直接通过修改 X、Y值 修改 Content 坐标。一直说的 Content 坐标，仅仅指的是编辑器设计UI时 Content 的 初始坐标 没有在运行时被体现出来。
我理解的伪代码：
scrollChange() {
content.x = content.initX + changedX;
content.y = content.initY + changedY;
}
运行时需要修改 Content 坐标的需求应该是不多的，即使有，目前也已经有很多接口可以用，这个不是我想讨论的。
编辑器与预览效果一致应该是必须的。
晕死，我也遇到了这问题，