開発モードでは、変更検出は最初の実行の直後に2回目の実行を行い、1回目と2回目の実行の間にバインドされた値が変更されるとエラーを生成します。これは、値のチェックに副作用があるバグや、Angularの変更検出を損なう後続の呼び出しでフィールドまたは関数が同じ値を返さないバグを見つけるのに役立ちます。
開発モードでは、2回目の変更検出の実行中に、Angularは、許可されていないモデルの変更を検出するために、運用環境では実行できない深層オブジェクト比較も行います。
更新：
開発モードでは、HTMLサニタイザーサービスがバインディング[innerHTML]="..."または[ngStyle]="..."から値を取り除くときに、コンソールにもヒントが出力されます。参照： RC.1では、一部のスタイルはバインディング構文を使用して追加できません
ApplicationRef.tick（） stateのドキュメント：
開発モードでは、
tick()は2回目の変更検出サイクル（TTL = 2）も実行して、変更が検出されないようにします。この2番目のサイクル中に追加の変更が検出された場合、アプリ内のバインディングには、単一の変更検出パスでは解決できない副作用があります。この場合、Angularはエラーをスローします。これは、Angularアプリケーションがすべての変更検出を完了する必要がある変更検出パスを1つだけ持つことができるためです。
追加の変更ができない理由は、実稼働モードでは変更検出が1回しか実行されないためです。つまり、コンポーネントツリー内のすべてのコンポーネントが1回（TTL = 1）から検査されます。注文。たとえば、子コンポーネントの入力プロパティの変更により、親コンポーネントがビュー/テンプレートでバインドしている他のプロパティが変更された場合、親コンポーネントのビューは更新されません（「ワンパス」ツリートラバーサルのため、変更検出は実稼働モードで親コンポーネントを再訪しないため）次回何らかのイベントが発生し、変更検出が再度実行されるときにのみ更新されますが、それは遅すぎます！
ルールに違反する Plunker があります。子コンポーネントには、別の入力プロパティを変更する入力プロパティにsetメソッドがあります。はい、それは不自然な例ですが、次の例よりも理解しやすいです：
この問題が発生する可能性がある別のシナリオは、ステートフルパイプを使用する場合です。 この答え を確認してください。それが問題である場合。
問題を説明する必要があります（別のSO質問）。それを修正する方法があるはずです。