您描述的观察结果与以下内容一致...

The observations you describe are consistent with the following ...

创建表单后，它会添加带有名称的字段

When your form is created, it adds fields with the names

mission_edit[options][0][tagname]
mission_edit[options][0][prix]
mission_edit[options][1][tagname]
mission_edit[options][1][prix]
mission_edit[options][2][tagname]
mission_edit[options][2][prix]

，当您添加其他两个选项时，它会添加:

and when you add two other option, it adds:

mission_edit[options][0][tagname]
mission_edit[options][0][prix]
mission_edit[options][1][tagname]
mission_edit[options][1][prix]

然后您将第一个选项(包括原始选项)留给了您.

and then you scrap the first option leaving you with (including the original options!)

mission_edit[options][0][tagname]
mission_edit[options][0][prix]
mission_edit[options][1][tagname]
mission_edit[options][1][prix]
mission_edit[options][2][tagname]
mission_edit[options][2][prix]
mission_edit[options][1][tagname]
mission_edit[options][1][prix]

，由于 php 将始终覆盖重复的var名称...您将使用新选项覆盖原始的第二个选项(索引为1).

and since php will always overwrite duplicate var names ... you overwrite your original second option (with the index 1) with the new option.

您应该通过实际查看DOM进行验证.如果我的假设是正确的，那么您会聪明地"在树枝模板中省略表单的特定部分，以创建原始元素，该元素可能位于 outside <ul>之外，而导致ul上的c2>计数器为0，并相应地覆盖元素.

You should verify by actually looking at the DOM. If my assumption is correct, than you "cleverly" omitted the specific part of your form in your twig templates, where the original elements are created, which is probably outside the <ul> which leads to the index counter on the ul to be 0, and overwriting the elements accordingly.

老实说，出于这个原因，我不喜欢使用symfony示例中的特定代码行-您也正在使用-

To be honest, I dislike using a specific line of code from the symfony example - which you're also using - for exactly that reason, the line of code is:

$collectionHolder.data('index', $collectionHolder.find(':input').length);

因为它使用了一组非显而易见的假设，特别是:您的子表单至少具有一个输入字段类型，事实并非如此！ (例如，可编辑+大量的js)，并且与您的示例相关，所有现有的子级都放在集合所有者中，而您不会这样做.为了公平起见，在这里显示出来的symfony示例是绝对可行的，因为这里的假设成立.

since it uses a non-obvious set of assumptions, particularly: your sub-form has at least one input type of field, which might not be the case! (e.g. editable + lots of js), and relevant for your example, that all existing children are put inside the collection holder, which you don't do. To be fair the symfony example where this is shown absolutely works, since the assumptions hold true there.

相反* 我会使用(*表示删除另一行代码！)

Instead* I would use (* meaning, removing the other line of code!)

<ul class="options" 
    data-prototype="{{ form_widget(edit_form.options.vars.prototype)|e('html_attr') }}"
    data-index="{{ edit_form.options.children|length }}"> {# <- this is the important part!! #}

    {# I would also add the existing children here, but there may be reasons not to! #}
</ul>

因为它正确地将索引设置为应该的子代数.

because it correctly sets the index to the number of children, which it is supposed to be.