核心问题应该是，content 节点的 x、y 初始坐标没有反映在 ScrollView 里（或者说初始坐标被组件重新赋值了），造成 content 节点的定位偏差。上次你给的解决方法是使用 Widget ，但那似乎没有在根本上解决这个确实存在的问题。
建议引擎组再讨论下，这个不是统一样式的问题。
手动调整 position 是不可行的，因为控件本身会修改初始值
我可以加载完内容后手动把 content 的坐标再赋值回去，但这样造成的结果就是 ScrollView 每次显示列表会间歇性错位。
你可以自己试试。
这种比较反认知的问题后续肯定有很多人反馈，建议还是趁早解决。
其实我理解上修改很简单，就是在定位时把 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赞
老实说现在的实现确实还是会有点复杂，不过我们没有找到更合适的方案。或许之后我们可以参考一下同类引擎的其它做法。