En el modo de desarrollo, la detección de cambios realiza una segunda ejecución inmediatamente después de la primera ejecución y produce un error si algún valor límite ha cambiado entre la primera y la segunda ejecución. Esto ayuda a localizar errores donde la verificación de valores tiene efectos secundarios o campos o funciones que no devuelven el mismo valor en llamadas posteriores, lo que socava la detección de cambios de Angular.

En el modo de desarrollo, durante la segunda ejecución de detección de cambios, Angular también realiza algunas comparaciones profundas de objetos que no realizará en producción para detectar cambios en el modelo que no están permitidos.

Actualizar:

En el modo de desarrollo, también se imprime una sugerencia en la consola cuando el servicio de desinfección de HTML elimina los valores de los enlaces [innerHTML]="..." o [ngStyle]="..." . Ver también: En RC.1, algunos estilos no se pueden agregar usando la sintaxis de enlace

Los documentos para ApplicationRef.tick() indican:

En el modo de desarrollo, tick() también realiza un segundo ciclo de detección de cambios (TTL=2) para garantizar que no se detecten más cambios. Si se detectan cambios adicionales durante este segundo ciclo, los enlaces en la aplicación tienen efectos secundarios que no se pueden resolver en un solo paso de detección de cambios. En este caso, Angular genera un error, ya que una aplicación de Angular solo puede tener una pasada de detección de cambios durante la cual se deben completar todas las detecciones de cambios.

La razón por la que no podemos tener cambios adicionales es porque en el modo de producción, la detección de cambios solo se ejecuta una vez, lo que significa que cada componente en el árbol de componentes se examina una vez (TTL=1)... desde arriba, primero en profundidad. pedido. Entonces, si, por ejemplo, un cambio en la propiedad de entrada de un componente secundario provoca un cambio en alguna otra propiedad que el componente principal haya vinculado en una vista/plantilla, la vista del componente principal no se actualizará (porque la detección de cambios no volverá a visitar la componente principal en el modo de producción... debido al recorrido del árbol de "una pasada"). Solo se actualizará la próxima vez que ocurra algún evento y la detección de cambios se ejecute nuevamente, ¡pero eso es demasiado tarde!

Aquí hay un Plunker que viola la regla: un componente secundario tiene un método set en una propiedad de entrada que modifica otra propiedad de entrada. Sí, es un ejemplo artificial, pero es más fácil de entender que el siguiente:

Otro escenario en el que podría encontrarse con este problema es con canalizaciones con estado. Mira esta respuesta si ese es tu problema.

Debe describir su problema (en otra pregunta SO). Debería haber una manera de arreglarlo.