其实我理解上修改很简单，就是在定位时把 content 节点的初始坐标考虑进去就可以了。
现在控件取的坐标应该只考虑了 view 的宽高
content 位置本身是不可调的，组件本身设计就是按照 content 内容不可调节设置的。content 位置是通过 View Boundary 定位的，你可以通过调节 View 的的边界来调整 content 的内容。不建议直接调节 content position。
对的，确实不能调，不是要在运行时调，只是要把 content 节点的初始位置考虑进去，因为他也是一个正常的node，如果不让设置初始值，请把content节点坐标设置为只读
非常感谢，不知道为什么之前初始位置有偏差。不过我们这边调整下新建的 Scrollview 中的 content 就行了吧？一般也不会有人去修改里面的东西。
设置好目前是没用的，详见demo
不是运行时调整，只要content节点的初始坐标跟之前版本一样能有效果就行。谢谢
达到的效果就是 content节点 在 ScrollView 滚动到初始位置时，与设置的初始位置坐标一样，这在我理解是合理的，况且，之前版本也都是这个效果。
目前是， content 节点滚动到的初始位置不是设置的初始位置，而是控件自己重新计算得到的一个值。
根据你目前的反馈，将在下个小版本时针对内置控件进行位置修正。感谢您的认真反馈。
目前 scrollview 控件目前经过调整 content 对象由对齐 ScrollView 父节点改为对齐 view 下一级父节点，如果希望两组对象呈现相同的效果建议手动调整 view 对象属性如下图：
最后呈现效果：
@xduooo
当然可以按你的改法（或者其他N种方法也可以）为了项目调整的让两者一致，
但目前，显示与预计效果不一致也是个问题啊，毕竟，不可能强迫开发者必须改哪个属性~~~
除非把某些属性改为只读，不让开发者修改。
谢谢反馈，你说的是没错的，这个后续会进行改进
这里其实 content 的坐标应该是只读的才对，它是根据 view 的坐标，大小来进行计算
你可以先重新赋值一下 content 来复位一下 content 的坐标
1、这边达到效果可以有很多种方法， 但希望 creator 功能设计上能够减少此类别扭的设计，就目前来看，scrollview这个设计思路，已经很别扭了，把content节点坐标改成只读很奇葩（content这样一个正常的 cc.Node 因受到歧视遭受10000点伤害），我认为正确的思路，应该是在之后的content坐标计算中，考虑他的初始坐标，就可以了。
2、重新赋值content坐标复位不可行，会莫名其妙的跳
-
因为你在编辑器不管怎么设置 content ，运行起来以后还是会根据 view 进行重新计算一次 content 的
-
不太可能把，你直接拖动 contnet 到
就可以了
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 坐标的需求应该是不多的，即使有，目前也已经有很多接口可以用，这个不是我想讨论的。
编辑器与预览效果一致应该是必须的。
晕死，我也遇到了这问题，